“Dumping current patch information” in Alert Log 12c can lead to a misinterpretation

Oracle Database 12.1 shows information on applied patches in the alert log during instance startup.

A question come up: The msg info in alert.log (below) is about patch applied on OH only or this information is related to patch applied on Database?

alert.log
...
2016-09-01 18:07:52.476000 -03:00
===========================================================
Dumping current patch information
===========================================================
Patch Id: 23144544
Patch Description: DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)
Patch Apply Time: 2016-08-31 17:44:09 GMT-03:00
...

To get the answer I installed a OH 12.1 without create a database and apply the DATABASE BUNDLE PATCH: 12.1.0.2.160719.

I created a CDB database  with DBCA using template General purpose or transaction processing.

During a database creation  was looking at alert log and I noticed two things.

First the alert log show:

===========================================================
Dumping current patch information
===========================================================
No patches have been applied
===========================================================

Then at end of database creation  alert log show:

...
2016-09-01 18:07:52.476000 -03:00
===========================================================
Dumping current patch information
===========================================================
Patch Id: 23144544
Patch Description: DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)
Patch Apply Time: 2016-08-31 17:44:09 GMT-03:00
...

The patch has been applied on my database during database creation?

The anwser is NO.
To my surprise, the “Dumping current patch information” is about Patches applied on OH only.

Why  “No Patches” the after some time “Show Patches”? 

The patch information is populated by calling DBMS_QOPATCH. It is populated if the database was started in a open mode, as it’s not possible to execute any package with database not opened in read-write.
At first moment database was started in a non-open mode , then NO PATCHES, when database was started in OPEN mode then alertlog was pouplated with the info.

Why this can lead a misinterpretation? 

DBMS_QOPATCH was introduced in 12c to query about Patch information  applied on database, but the info on alert.log is not about patch applied on database, the info is about patch applied on OH only, it can lead us to think wich database have listed patch on alertlog applied.

(I think this is some bug or something else, because it makes no sense to me)

What is the safe mode to check if database have a patch applied?

 

conn as sysdba

SQL> set serverout on
SQL> exec dbms_qopatch.get_sqlpatch_status;

PL/SQL procedure successfully completed.

No outuput then No Patch applied.

After create database I checked if patch was applied and none patch was applied, but the “Dumping current patch information”  show all applied patch in the alertlog at startup of instance.

 

How to apply a BP or PSU on Database 12c?

By executing datapatch utility.

./datapatch -h
SQL Patching tool version 12.1.0.2.0 on Thu Sep 1 19:35:49 2016
Copyright (c) 2016, Oracle. All rights reserved.

sqlpatch usage:
All arguments are optional, if there are no arguments sqlpatch
will automatically determine which SQL scripts need to be run in
order to complete the installation of any SQL patches.

Optional arguments:
-db <db name>
 Use the specified database rather than $ORACLE_SID
-bundle_series <bundle_series>
 Specify if the patch is a bundle patch
 Should also be accompanied by -force option
 if -bundle_series option is specified,only 1 patch will
 be considered by the -force command
-apply <patch1,patch2,...,patchn>
 Only consider the specified patch list for apply operations
-rollback <patch1,patch2,...,patchn>
 Only consider the specified patch list for rollback operations
-upgrade_mode_only
 Only consider patches that require upgrade mode
-force
 Run the apply and/or rollback scripts even if not necessary
 per the SQL registry
-pdbs <pdb1,pdb2,...,pdbn>
 Only consider the specified list of PDBs for patching. All
 other PDBs will not be patched
-prereq
 Run prerequisite checks only, do not actually run any scripts
-oh <oracle_home value>
 Use the specified directory to check for installed patches
-verbose
 Output additional information used for debugging
-help
 Output usage information and exit
-version
 Output build information and exit

Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
(Doc ID 1585822.1)

Let’s  apply the patch.

cd $ORACLE_HOME/OPatch
./datapatch -verbose

Suprise: When execute ./datapatch -verbose it has no warning or confirmation, the datapatch automatically  will apply patch in  all CDBs and in all opened PDBs of current OH environment.

The same concern that we have about “dd” command, we must have about datapatch command. Hope Oracle fix it.

Output:

./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 on Thu Sep 1 18:28:47 2016
Copyright (c) 2016, Oracle. All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/
sqlpatch_23003606_2016_09_01_18_28_47/sqlpath_invocation.log

Connecting to database...OK
Note: Datapatch will only apply or rollback SQL fixes for PDBs
 that are in an open state, no patches will be applied to closed PDBs.
 Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
 (Doc ID 1585822.1)
Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of SQL patches:
Bundle series DBBP:
 ID 160719 in the binary registry and not installed in any PDB

Adding patches to installation queue and performing prereq checks...
Installation queue:
 For the following PDBs: CDB$ROOT PDB$SEED
 Nothing to roll back
 The following patches will be applied:
 23144544 (DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544))

Installing patches...
Patch installation complete. Total patches installed: 2

Validating logfiles...
Patch 23144544 apply (pdb CDB$ROOT): SUCCESS
 logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/23144544/20355564/23144544_apply_
PRDCDB_CDBROOT_2016Sep01_18_29_26.log (no errors)
Patch 23144544 apply (pdb PDB$SEED): SUCCESS
 logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/23144544/20355564/23144544_apply_
PRDCDB_PDBSEED_2016Sep01_18_32_36.log (no errors)
SQL Patching tool complete on Thu Sep 1 18:34:54 2016

datapatch always validate if a BP or PSU already was applied  as show below:

./datapatch -verbose
SQL Patching tool version 12.1.0.2.0 on Thu Sep 1 18:35:21 2016
Copyright (c) 2016, Oracle. All rights reserved.

Log file for this invocation: /u01/app/oracle/cfgtoollogs/sqlpatch/
sqlpatch_23593462_2016_09_01_18_35_21/sqlpatch_invocation.log

Connecting to database...OK
Note: Datapatch will only apply or rollback SQL fixes for PDBs
 that are in an open state, no patches will be applied to closed PDBs.
 Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation
 (Doc ID 1585822.1)
Bootstrapping registry and package to current versions...done
Determining current state...done

Current state of SQL patches:
Bundle series DBBP:
 ID 160719 in the binary registry and ID 160719 in PDB CDB$ROOT, 
 ID 160719 in PDB PDB$SEED

Adding patches to installation queue and performing prereq checks...
Installation queue:
 For the following PDBs: CDB$ROOT PDB$SEED
 Nothing to roll back
 Nothing to apply

SQL Patching tool complete on Thu Sep 1 18:35:53 2016

 

Checking what patches have been applied (or rolled back) on database

SQL> set serverout on
SQL> exec dbms_qopatch.get_sqlpatch_status;

Patch Id : 23144544
 Action : APPLY
 Action Time : 01-SEP-2016 18:34:46
 Description : DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)
 Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/23144544/20355564/23144544_apply_PRDCDB_CDB
ROOT_2016Sep01_18_29_26.log
 Status : SUCCESS

PL/SQL procedure successfully completed.

 

Some notes:

  • Patch Information in Alert Log is about OH only
  • Creating a Database a CDB or Non-CDB database using a default Template it does not apply any Patch, you must apply patch manually after database creation.
  • datapatch utility is dangerous because has no warning or confirmation when executed.

 


Matrix de Compatibilidade para Upgrade Oracle 10g/11g

Requerimentos para UPGRADE

  • Faça dowload e instale o Oracle 11g/11g Release 2 em um novo  Oracle Home e tenha certeza que a instalação foi finalizada sem erros.
  • Instale os ultimos Patchset do Metalink ( se disponivel)
  • Instale os ultimos Critical Patch Updade (CPU) (se disponivel)
  • Faça um Backup Full do seu banco de dados ( aconselhamos um backup off-line)
  • Verifique a compatiblidade UPGRADE/DOWNGRADE antes de atualizar o Banco de Dados.
Matrix de Compatibilidade 10G

Minima versão de banco de dados que pode diretamente ser atualizada para Oracle 10g Release 2

Source Database       Target Database
8.1.7.4 ->                    10.2.X.X.X
9.0.1.4 or 9.0.1.5 -> 10.2.X.X.X
9.2.0.4 or higher -> 10.2.X.X.X
10.1.0.2 or higher -> 10.2.X.X.X

A seguintes versões irao requerer passos adicionais

Source Database —> Upgrade Path for Target Database—>Target Database
7.3.3 (or lower) -> 7.3.4 -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X
7.3.4 -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X
8.0.n -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X
8.1.n -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X

Matrix de Compatibilidade 11G

Minima versão de banco de dados que pode diretamente ser atualizada para Oracle 11g Release 2

Source Database               Target Database
9.2.0.8 or higher              11.2.x
10.1.0.5 or higher            11.2.x
10.2.0.2 or higher           11.2.x
11.1.0.6 or higher             11.2.x

A seguintes versões irao requerer passos adicionais

Source Database —> Upgrade Path for Target Database—>Target Database
7.3.3 (or lower)—–> 7.3.4 —> 9.2.0.8 —->                             11.2.x
8.0.5 (or lower)—-> 8.0.6 —> 9.2.0.8 —->                              11.2.x
8.1.7 (or lower)—-> 8.1.7.4—> 10.2.0.4—->                          11.2.x
9.0.1.3 (or lower)—-> 9.0.1.4– ->10.2.0.4—->                      11.2.x
9.2.0.7(or lower)—-> 9.2.0.8—->                                                 11.2.x

 

Ver nota Oracle 316889.1 e 870814.1

Aproveite!!!


Desfragmentando Tabelas no Oracle 10g/11g

Neste Post irei mostrar um dos caminhos para realizar a desfragmentação de tabelas no Oracle 10g/11g.

Quando preciso desfragmentar uma tabela?

Se a sua tabela recebe apenas inserções (insert) de dados, você nao precisa se preocupar porque  ela nunca terá problemas de fragmentação.

O problema da fragmentação aparece quando atualizamos ou apagamos (update/delete)  dados na tabela.

Os espaços que  são liberados durante as operações (update/delete) não são imediatamente re-utilizado. Isto resulta em “espaços livre/blocos de dados espalhados nas tablespaces ”  que são chamados de fragmentação de dados.

Vamos entender como o Oracle gerencia os espaços das tabelas.

Acredito que você ja ouviu falar em HWM (High water mark) nós conhecemos como marca d’agua.

Para entender melhor vamos fazer uma analogia, se você olhar dentro de uma caixa d’agua  você vai ver uma linha (marca) proximo a borda entre o lugar que sempre tem agua e o lugar que nunca tem agua.

Do mesmo jeito acontece no Oracle a HWM define uma linha (marca) entre os blocos que foram utilizados e os blocos que nunca foram utilizados.

A marca dágua – HWM é o limite do número de blocos que uma tabela pode estar utilizando.

Quando realizamos uma leitura completa da tabela (full table scan, FTS), o Oracle sempre ira ler todos os blocos utilizados até a marca d’agua. Se existir muitos blocos livres que já foram utilizados até a marca d’agua, estes espaços livres (blocos) também serão lidos , isto gerar I/O extra e seu ambiente irá ter perda de perfomance durante operações de FTS.

Vamos identificar a marca d’agua na tabela e nós iremos saber se a tabela é candidata a reorganização.

Encontraremos 2 tipos de blocos que devemos nós preocupar:

Unused Space/empty_blocks – Que nunca foram utilizado.

Free Space/Blocks – Blocos sofreram  update e delete

SQL> create table teste_hwm as select * from dba_objects;
Table created.
SQL> analyze  table teste_hwm compute statistics;
Table analyzed.
SQL> select blocks "Usados",
 2  empty_blocks "Nunca Utilizado",
 3  num_rows "Total de Linhas"
 4  from user_tables
 5  where table_name='TESTE_HWM';

 Usados Nunca Utilizado Total de Linhas
---------- --------------- ---------------
 1016               7           69072
SQL> delete from teste_hwm
 2  where owner ='SYS';

30219 rows deleted.

SQL> commit;
Commit complete.

Percebe que não houve diferença nos blocos utilizado.

SQL> select blocks "Usados",
 2  empty_blocks "Nunca Utilizado",
 3  num_rows "Total de Linhas"
 4  from user_tables
 5  where table_name='TESTE_HWM';

 Usados Nunca Utilizado Total de Linhas
---------- --------------- ---------------
 1016               7           38853

Se você tem um ambiente que possui tabelas que sofrem muitas modificações (update/delete), periodicamente você ira precisar desfragementar suas tabelas.

Verifique a necessidade de Reorganização

  • Baixo tempo de resposta (por tabela)
  • Alto numero de linhas encadeadas (na verdade migrada)
  • Tabela está crescendo e espaço antigo nao está sendo liberado

Nota: As consultas que utilizam indices não irá ter muito beneficio comparadas com as consultas que utilizam leitura completa (FTS).

Vamos reorganizar

Nas versões anteriores ao Oracle 10g , tinhamos 3 maneiras  de reorganizar as tabelas.

  1. Export, Import e Drop
  2. Usar o recurso Online Object Redefinition
  3. Usar o comando Alter table move (para outra tablespace ou na mesma)

Já no Oracle 10g conseguimos uma outra  maneira de reorganizar os dados.

O comando Shrink: Este comando é aplicado somente em tabelas armazenado em  Tablespace com AUTO SEGMENT SPACE MANAGEMENT.

Antes de usar o SHRINK deve ser habilitado a opção ROW MOVEMENT  na tabela.

SQL> alter table teste_hwm enable row movement;

Table altered.

Existe 2 maneiras de executar o SHRINK.
1 – Executar em Duas etapas – Se estiver preocupado com disponibilidade da tabela
2 – Executar em Uma etapa – Se não estiver preocupado com disponibilidade da tabela

Eu sempre utilizo este comando em duas etapas.

Primeira etapa iremos realizar a reorganização das linhas da tabelas.
Durante esta etapa todas DML’s continuam ocorrendo. Esta etapa é a mais demorada.
Dependendo do tamanho da sua tabela este processo pode demorar horas.

SQL> alter table teste_hwm shrink space compact;

Table altered.
Elapsed: 00:00:02.89

Segunda etapa iremos resetar a marca d’agua (HWM).
Nesta etapa a tabela não pode sofrer DML, porém esta etapa é muito rapida.

SQL> alter table teste_hwm shrink space;

Table altered.
Elapsed: 00:00:00.27

Ou Podemos executar este processo em uma etapa. O Oracle irá realizar a reorganização das linhas (rows ) e ira resetar o HWM.

SQL> alter table teste_hwm shrink space;

Table altered.

Agora vamos ver a marca d’agua:

SQL> analyze  table teste_hwm compute statistics;
Table analyzed.
SQL> select blocks "Usados",
 2  empty_blocks "Nunca Utilizado",
 3  num_rows "Total de Linhas"
 4  from user_tables
 5  where table_name='TESTE_HWM';

 Usados Nunca Utilizado Total de Linhas
---------- --------------- ---------------
590                   26           38853

A diferença entre o anterior é agora é de aproximadamente 50%, isto significa aumento de performance no meu ambiente, pois não precisarei ler blocos desnecessários durante o FTS.

Cuidados a serem tomados :
– Executando o shrink space sem o compact a tabela não poderá ser acessada durante o processo de desfragmentação.
– Caso você execute o shrink space compact e demore muito tempo para executar o shrink space para resetar o HWM, a tabela já poderá estar desfragmentada e este ultimo comando irá demorar mais que o esperado, pois ele irá primeiro desfragmenta os dados depois realizar o reset.
– Dependendo do tamanho da tabela você tem que se preocupar com o Tamanho da Tablespace de UNDO e com o parametrô UNDO_RETENTION.

Vantagens:
– Diferente do “alter table move” os indices não estarão com o status UNUSABLE.
Depois do comando shrink os indices são atualizados também.

– Não precisaremos de downtime para realizar a reorganização das tabelas.

– Não requer espaço extra para executar este processo.

Aproveite !!!


Grid Plug and Play (GPnP)

A Oracle na versão 11g R2 introduziu um novo recurso chamando Grid Plug and Play (GPnP), este novo recurso foi criado para resolver problemas de configurações de parâmetros entre os nós de um Cluster. O conceito de GRID é você conectar e desconectar itens de um cluster sem a necessidade de configurações adicionais (ou o mais próximo disto), realizando isto de uma forma mais invisível possível.

Então pensando  no trabalho de configuração que um DBA até hoje tem nas versões anteriores em configurar um Cluster a Oracle criou ou GPnP.

GPnP elimina a necessidade de configuração por nó , exemplo se adicionarmos um novo nó e o Oracle estiver funcionando com o GNS o Oracle ira gerenciar o fornecimento de novos IP para aquele novo nó sem a necessidade do DBA solicitar novos IPs para o Administrador de Rede, toda configuração é automatica e transparente.

GPnP – Grid Plug and Play

  • É um conceito  base  do GRID  que permite a automatização das operações do cluster.
  • Permite adicionar ou remover dinamicamente nós do cluster
  • Fornece uma gestão mais fácil para construir grandes Clusters.
  • É a base para um novo recurso chamado Grid Naming Service (GNS)

Tecnicamente, GPnP é baseado em um profile XML

  • Definição da personalidade do Nó (ex. Rede publica/privada, caminho do arquivos de inicialização-ASM )
  • É criado durante a instalação do Cluster
  • É atualizada toda vez existem mudanças relevantes (usando oifcfg, crsctl)
  • É armazenado em arquivos locais por nó e no OCR
  • É protegido com assinaturas digital

Durante a instalação do Oracle Clusterware 11g R2 , não é solicitado  a identificação ou configuração de Rede Privada no OUI.

Isto deve ao GPnP que realiza tarefas que é necessária, mas não precisamos ser solicitado a desempenha – lá.

Na instalação é criado no seguinte diretorio;

  • $GRID_HOME/gpnp/$hostname/profile/peer/profile.xml
  • $GRID_HOME/gpnp/profile/peer/profile.xml (global backup)

Replicado pelo gpnpd durante a instalação, inicialização do sistema, or quando atualizando utilizando as ferramentas de cluster abaixo:

  • oifcfg – Configuração de Rede
  • crsctl  – Configuração do CSS
  • ASM  – Adicionar armazenamento (Diskgroup)

O GPnP  possui um processo no sistema operacional.

Sistema Linux/Unix

  • Processo de Sistema Operacional – gpnpd.bin
ps -ef |grep gpnpd
oracle    4793     1  0 11:50 ?        00:00:02 /u01/app/11.2.0/grid_crs/bin/gpnpd.bin

Sistemas Windows

  • Serviço do Windows - OracleOHService
  • Processo -  gpnpd.exe

Em breve estarei postando uma matéria sobre GNS.

Aproveite!!!


Relatório Oracle DB Verify

Você sabia que é possivel realizar Backup via RMAN de blocos Corrompidos?
Sim, é possivel.

E se você não estiver se preocupando com isto você pode ter um Backup queimado e ser impossiblitado de realizar o Recovery.

Para isto você deve usar periodicamente o DBV ou alterar um parametro no banco para realizar a verificação dos blocos logicos do Oracle.

Recentemente precisei analizar um log do DBVERIFY de um banco de dados que tinha mais de 500 datafiles.

Para facilitar nossa vida eu criei um pequeno codigo que lê e importa a saida do arquivo de log do DBV.

Consulta que gera a o script para a execução do DBVERIFY.

set echo off feedback off verify off pages 0 termout off  linesize 150
spool dbv_check.ksh
 select 'dbv userid=system/xxxx file=' || name || ' blocksize=' || block_size ||
 ' feedback=' || round(blocks*.10,0) -- 10 dots per file
 from v$datafile;
 spool off

Iremos criar um objeto Oracle Directory onde iremos colocar os arquivos de log .

-- Criar o Diretorio no S.O
mkdir -p /u01/app/external_tables/dba
-- Criar Oracle DIRECTORY
DROP DIRECTORY EXT_DBA_DIR;
CREATE DIRECTORY "EXT_DBA_DIR" AS '/u01/app/external_tables/dba';

Nós iremos criar uma External Table que irá ler o arquivo de log DBV_OUTPUT.LOG no diretorio “/ u01/app/external_tables/dba”.

-- CREATE EXTERNAL TABLE

-- DROP TABLE TBE_DBV_OUTPUT PURGE;

 CREATE TABLE "TBE_DBV_OUTPUT"
 (
 "FULL_TEXT" VARCHAR2(2555 CHAR)
 )
 ORGANIZATION EXTERNAL
 (
 TYPE ORACLE_LOADER DEFAULT
 DIRECTORY "EXT_DBA_DIR" LOCATION ( "EXT_DBA_DIR":'DBV_OUTPUT.LOG' )
 );

Iremos Criar uma tabela que irá armazenar os Itens a serem analizado pelo DBV and e inserir os itens existentes.

-- CREATE TABLE ITENS OF DBV
 DROP TABLE TB_DBV_ITENS PURGE;
 CREATE TABLE "TB_DBV_ITENS"
 (
 "ID"    NUMBER,
 "ITENS" VARCHAR2(400 BYTE)
 );

 --------------------------------------------------------------------------------------------------------
 ALTER TABLE TB_DBV_ITENS MODIFY   (ID NOT NULL) ;
 --------------------------------------------------------------------------------------------------------
 ALTER TABLE TB_DBV_ITENS ADD CONSTRAINT TB_DBV_ITENS_PK PRIMARY KEY  (ID) ENABLE;
--------------------------------------------------------------------------------------------------------
--  REM INSERTING into TB_DBV_ITENS
Insert into TB_DBV_ITENS (ID,ITENS) values (1,'Total Pages Failing   (Data) ');
Insert into TB_DBV_ITENS (ID,ITENS) values (2,'Total Pages Processed (Other)');
Insert into TB_DBV_ITENS (ID,ITENS) values (3,'Total Pages Examined         ');
Insert into TB_DBV_ITENS (ID,ITENS) values (4,'Total Pages Processed (Data) ');
Insert into TB_DBV_ITENS (ID,ITENS) values (5,'Total Pages Processed (Index)');
Insert into TB_DBV_ITENS (ID,ITENS) values (6,'Total Pages Marked Corrupt   ');
Insert into TB_DBV_ITENS (ID,ITENS) values (7,'Total Pages Failing   (Index)');
Insert into TB_DBV_ITENS (ID,ITENS) values (8,'Total Pages Processed (Seg)  ');
Insert into TB_DBV_ITENS (ID,ITENS) values (9,'Total Pages Failing   (Seg)  ');
Insert into TB_DBV_ITENS (ID,ITENS) values (10,'Total Pages Influx           ');
Insert into TB_DBV_ITENS (ID,ITENS) values (11,'Total Pages Empty            ');
Insert into TB_DBV_ITENS (ID,ITENS) values (12,'Highest block SCN            ');
COMMIT;

 

Iremos criar uma tablela que ira armazenar o nome dos datafiles e tempo gasto na analise e versão do DBV.

 --- CREATE TABLE DBV_DATAFILES
 DROP TABLE TB_DBV_DATAFILES PURGE;
 CREATE TABLE "TB_DBV_DATAFILES"
 (
 "ID"            NUMBER NOT NULL ENABLE,
 "DATAFILE_NAME" VARCHAR2(500 BYTE),
 "ELAPSED"       VARCHAR2(100 BYTE),
 "DBV_VERSION"   VARCHAR2(200 BYTE)
 ) ;

COMMENT ON COLUMN "TB_DBV_DATAFILES"."ELAPSED" IS 'HH24:MI:SS';

We will create a table to store the results of analyzed items during the process of DBV.

 ---------------------------------------------------------------------------------------------------------
 DROP TABLE TB_DBV_ITENS_VALUES PURGE;
 CREATE TABLE "TB_DBV_ITENS_VALUES"
 (
 "DATAFILE_NAME" NUMBER,
 "ITENS"         NUMBER,
 "ITENS_VALUES"  VARCHAR2(300 BYTE))
 ;

Iremos criar uma função para calcular o tempo gasto durante a analise do datafile.

create or replace
function datediff(                       p_d1   in date,
 p_d2   in date ) return date
 as
 l_result    date;
 begin
 select to_date(to_char(mod(floor((p_d1-p_d2)*24),24),'00')
 || ':' ||
 to_char(mod(floor((p_d1-p_d2)*24*60),60),'00')
 || ':' ||
 to_char(mod(floor((p_d1-p_d2)*24*60*60),60),'00'),'HH24:MI:SS')
 into l_result from dual;
 return l_result;
 end;
/


Criaremos também uma sequencia que será usada como ID da tabela que irá armazenar o nome dos Datafiles

DROP SEQUENCE SEQ_ID_DATAFILE;

CREATE SEQUENCE SEQ_ID_DATAFILE INCREMENT BY 1 START WITH 1 MAXVALUE 9999999999999999999999999999 MINVALUE 1 CACHE 20;
 

Agora iremos criar uma Procedure que irá carregar os dados no banco de dados

 create or replace
PROCEDURE LOAD_DBV_LOG
AS
 vDBV_FULL_TEXT VARCHAR2(2555);
 vDBV_VERSION   VARCHAR2(100);
 vDBV_TIME1 DATE;
 vDBV_TIME2 DATE;
 vDBV_FILE         VARCHAR2(1300);
 vDBV_ITENS        VARCHAR2(4000);
 vDBV_ITENS_VALUES VARCHAR2(300);
 vDBV_DATAFILE     VARCHAR2(1000);
 v_id_datafile     NUMBER;
 vDBV_ITENS_ID     NUMBER;
 vDBV_ELAPSED      VARCHAR2(200);
 v_id_datafile_aux NUMBER;
BEGIN
 DELETE TB_DBV_ITENS_VALUES;
 COMMIT;

 DELETE TB_DBV_DATAFILES;
 COMMIT;

 FOR DBV_INPUT IN
 (SELECT FULL_TEXT FROM TBE_DBV_OUTPUT
 )
 LOOP
 BEGIN
 vDBV_FULL_TEXT := DBV_INPUT.FULL_TEXT;
 BEGIN
 IF SUBSTR(vDBV_FULL_TEXT,1,17) = 'DBVERIFY: Release' THEN
 vDBV_TIME2                  := vDBV_TIME1;
 vDBV_VERSION                := SUBSTR(vDBV_FULL_TEXT,19,10);
 vDBV_TIME1                  := TO_DATE(UPPER(SUBSTR(vDBV_FULL_TEXT,50)),'MON DD HH24:MI:SS YYYY');
 END IF;
 END;
 BEGIN
 IF SUBSTR(vDBV_FULL_TEXT,1,41) = 'DBVERIFY - Verification starting : FILE =' THEN
 v_id_datafile_aux           := v_id_datafile;
 vDBV_DATAFILE               := SUBSTR(vDBV_FULL_TEXT,43);
 v_id_datafile               := SEQ_ID_DATAFILE.nextval;
 INSERT
 INTO TB_DBV_DATAFILES
 (
 ID,
 DATAFILE_NAME,
 DBV_VERSION
 )
 VALUES
 (
 v_id_datafile,
 vDBV_DATAFILE,
 vDBV_VERSION
 );
 COMMIT;
 IF v_id_datafile_aux IS NOT  NULL THEN
 SELECT TO_CHAR(DATEDIFF(vDBV_TIME1,vDBV_TIME2),'HH24:MI:SS') INTO vDBV_ELAPSED FROM DUAL;
 UPDATE TB_DBV_DATAFILES SET ELAPSED=vDBV_ELAPSED WHERE ID = v_id_datafile_aux;
 COMMIT;
 END IF;
 END IF;
 END;
 BEGIN
 IF SUBSTR ( vDBV_FULL_TEXT,1,11 ) = 'Total Pages' OR SUBSTR ( vDBV_FULL_TEXT,1,7 ) = 'Highest' THEN
 SELECT ID
 INTO vDBV_ITENS_ID
 FROM TB_DBV_ITENS
 WHERE ITENS        = SUBSTR(vDBV_FULL_TEXT,1,29);
 vDBV_ITENS_VALUES := SUBSTR(vDBV_FULL_TEXT,32);
 INSERT
 INTO TB_DBV_ITENS_VALUES
 (
 ITENS,
 DATAFILE_NAME,
 ITENS_VALUES
 )
 VALUES
 (
 vDBV_ITENS_ID,
 v_id_datafile,
 vDBV_ITENS_VALUES
 );
 COMMIT;
 END IF;
 END;
 END;
 END LOOP;
END;
/

Concluindo iremos criar uma VIEW que irá retornar os valores das tabelas igual a saida de log do DBV_LOG

CREATE OR REPLACE FORCE VIEW "REPORT_DBV"
AS
 SELECT DF.DATAFILE_NAME,
 DF.DBV_VERSION,
 DF.ELAPSED,
 I.ITENS,
 IV.ITENS_VALUES
 FROM TB_DBV_DATAFILES DF ,
 TB_DBV_ITENS I ,
 TB_DBV_ITENS_VALUES IV
 WHERE IV.DATAFILE_NAME = DF.ID
 AND IV.ITENS           = I.ID;

Exemplo de Execução:

Gerando o Arquivo de Log DBV

cat dbv_check.ksh
dbv userid=system/xxxx file=+DG_DATA/tsm/datafile/system.256.71328 blocksize=8192 feedback=11776

Saida do DBV:

DBVERIFY: Release 10.2.0.5.0 - Production on Sun Sep 12 05:17:28 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - Verification starting : +DG_DATA/tsm/datafile/system.256.71328

DBVERIFY - Verification complete

Total Pages Examined         : 655360
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 8
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 655352
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 0 (0.0)

Após colocarmos o log no diretorio /u01/app/external_tables/dba, só conectar no Oracle e executar a Procedure

SQL*Plus: Release 11.2.0.1.0 Production on Thu Sep 16 15:39:49 2010

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Release 11.2.0.1.0 - Production
With the Automatic Storage Management option

SQL> exec load_dbv_log;

PL/SQL procedure successfully completed.


Com uma simples consulta….

SET UNDERLINE =
SET PAGESIZE 15
SET LINESIZE 200
BREAK ON DATAFILE_NAME ON DBV_VERSION ON  ELAPSED SKIP 1;
COL DATAFILE_NAME FOR A50
COL DBV_VERSION FOR A14
COL ELAPSED FOR A10
COL ITENS FOR A30
COL IVALUES FOR A10
SELECT DATAFILE_NAME, DBV_VERSION, ELAPSED, ITENS, ITENS_VALUES AS IVALUES
FROM REPORT_DBV
WHERE   DATAFILE_NAME LIKE '%system%'


Nós conseguimos isto…

DATAFILE_NAME                                      DBV_VERSION    ELAPSED    ITENS                          IVALUES
================================================== ============== ========== ============================== ==========
+DG_DATA/tsm/datafile/system.256.71328             10.2.0.5.0     00:00:43   Total Pages Failing   (Data)   0
                                                                             Total Pages Processed (Other)  692853
                                                                             Total Pages Examined           1310720
                                                                             Total Pages Processed (Data)   194873
                                                                             Total Pages Processed (Index)  51889
                                                                             Total Pages Marked Corrupt     0
                                                                             Total Pages Failing   (Index)  0
                                                                             Total Pages Processed (Seg)    0
                                                                             Total Pages Failing   (Seg)    0
                                                                             Total Pages Influx             0
                                                                             Total Pages Empty              371105
                                                                             Highest block SCN              0 (0.0)

Ainda falta alguns aprimoramentos no código, pois este código não importamos para o banco informaçoes dos blocos corrompidos somente mostramos quantas falhas existem no datafile.

Em breve estarei finalizando…

Use usa imaginação….

Aproveite!!!


Oracle Single Client Access Name (SCAN)

Single Client Access Name (SCAN) é um novo recurso do Oracle Real Application Clusters (RAC) 11g Release 2 que fornece um unico nome para os clientes acessar os bancos de dados em um cluster.
O beneficio para os clientes que usam o SCAN é que eles não precisaram de mudanças de configurações se adicionarmos ou removermos nós no cluster.
Ter um único nome para acessar o cluster permite os clientes usar conexões do tipo EZConnect ou usar o JDBC thin URL para acessar qualquer banco de dados no cluster independente de que servidor está ativo. SCAN fornece balanceamento de carga e failover para as conexões dos clientes nos bancos de dados.
O SCAN funciona como um IP apelido (alias) para o cluster.

 sqlplus system/oracle@cluster-scan:1521/orcl
 jdbc:oracle:thin@cluster-scan:1521/orcl
 

Requisitos de Rede para a Utilização do SCAN

O SCAN é configurado durante a instalação do Grid Infrastructure que é distribuido com o Oracle Database 11g R2.
Durante as fases de instalação do Grid Infrastructure, será necessário configurar o SCAN.
Existe duas opções para definir o SCAN:

  1. Definir o SCAN no seu DNS (Domain Name Server)
  2. Usar o Grid Naming Service (GNS)

Se voce escolhe a opção 1, você solicitar ao seu administrador para criar um unico nome para resolver 3 endereços de IPs usando o algoritimo round robin. Os endereços de IP devem estar na mesma subnet que a rede publica do cluster. O nome deve conter menos que 15 caracteres sem incluir o dominio e deve ser resolvido sem o sufixo do domino. (ex: cluster-scan deve ser resolvido). Os IPS não devem ser configurados em nenhuma interface de rede o Oracle Clusterware irá tomar conta disto.

Importante: O DNS utilizando o algoritimo round robin por conta propria não suporta failover para as conexões, mas não se preocupe o Oracle Client 11g R2 toma conta disto. Por isto é altamente recomentado utilizar o Cliente na versão 11g R2.

Se você escolher a opçao 2, voce irá precisar apenas definir um nome para o SCAN e durante a configuração do cluster, três endereços de IPs ira ser adquirido do serviço de DHCP (usando GNS asume que você tenha o serviço de DHCP disponivel em sua rede publica) criando o SCAN a resoluçao de nome para o SCAN será fornecida pelo GNS).

Não entrarei em detalhes do GNS, em breve estarei postando algo sobre GNS, mas basicamente o GNS do Oracle funciona como um DHCP secundario.

Configurando o SCAN no Cluster

Durante a configuração do Cluster, muitos recursos são criados no cluster para o SCAN. Para cada um dos 3 endereços de IPs que O SCAN resolve, um recurso SCAN VIP é criado e um SCAN LISTENER é criado. O SCAN Listener é dependente do SCAN VIP e 3 SCAN VIP (juntos com seu SCAN LISTENER associados) irão ser espalhados pelo cluster. Isto significa que iremos ter um par de recurso (SCAN VIP e SCAN LISTENER) em um nó diferente do cluster. Se o nó onde está executando o SCAN VIP vier falhar, o SCAN VIP e SCAN Listener associado irá executar o Failover para outro nó ativo do cluster.

Exemplo de configuração do SCAN.

 $srvctl config scan_listener
 SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521
 SCAN Listener LISTENER_SCAN2 exists. Port: TCP:1521
 SCAN Listener LISTENER_SCAN3 exists. Port: TCP:1521
 $srvctl config scan
 SCAN name: cluster-scan, Network: 1/192.168.217.0/255.255.255.0/
 SCAN VIP name: scan1, IP: /cluster-scan.mycompany.com/192.168.217.143
 SCAN VIP name: scan2, IP: /cluster-scan.mycompany.com/192.168.217.99
 SCAN VIP name: scan3, IP: /cluster-scan.mycompany.com/192.168.217.100
 

Configurando Banco de Dados para utilizar o SCAN

No banco de Dados 11g R2, o parametro do banco de dados REMOTE_LISTENER deve ser configurado para SCAN. Isto permite as instancias registrar o SCAN LISTENERs fornecendo informações quais serviços estão sendo fornecido pela instancia, carga corrente, e uma recomendação de quantas conexões de entrada devem ser dirigidas para a instância.
O parametro LOCAL_LISTENER deve ser configurado com o Listener que está utilizando o ip VIP.
Não configure REMOTE_LISTENER no TNSNAMES como e utilize como apelido (alias), o REMOTE_LISTENER deve ser configurando da seguinte forma:
REMOTE_LISTENER=SCAN:PORTA
Ex:
REMOTE_LISTENER=cluster-scan:1521

Balanceamento de Carga utilizando o SCAN

Para conexões dos clientes,o SQL*NET (11g R2) irá ter os 3 endereços de IP que o SCAN ira resolver. Ele ira receber a lista de IP do DNS e tentar conectar no LISTENER associado ao IP utilizado naquele momento.
Se o Cliente receber um erro, ele irá tentar outro IP antes de retornar o erro ao cliente. Isto é similar com os failover das conexões de versões anteriores , quando uma lista de endereços era configurada no Service Name no TSNNAMES.

Quando o SCAN LISTENER recebe uma conexão, o SCAN LISTENER ira verificar a instancia com a menor carga de trabalho. Ira então redirecionar a conexão requisitada para o Listener Local do nó para instancia com a menor carga.
O Cliente ira receber o endereço do Listener local e será capaz de resolver o endereço do node VIP. O Listener Local irá criar a conexão com a instancia do banco de dados.

Importante: Se seu cliente ORacle é uma versao anterior a 11G R2, você nao irá conseguir utilizar todos as funcionalidades do SCAN. O Oracle Client ira obter apenas um SCAN IP (retornado pelo DNS) e tentará conectar naquele endereço. Se o SCAN LISTENER não estiver disponivel, a conexão ira falhar e o usuario receberá a mensagem de erro. Se quiser utilizar a funcionalidade de balanceamento de carga e failover com clientes versão anteriores a 11G R2 , você ira precisar usar os 3 endereços de IP do SCAN no TNSNAMES.

ex:

 orcl.mycompany.com =(DESCRIPTION=
 (ADDRESS_LIST= (LOAD_BALANCE=on)(FAILOVER=ON)
 (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.217.43)(PORT=1521))
 (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.217.99)(PORT=1521))
 (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.217.100)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME= orcl.mycompany.com)))
 

Recomendo fortemente é utilizar o Cliente Oracle na mesma versão do Oracle Database.

Este documento foi criado com base no Oracle Technical Paper criado por Barb Lundhild.

Aproveite!!!


Oracle Validated RPM

Quem já utilizou o ORARUN em Linux SUSE, agora  pode utilizar o ORACLE VALIDATED (que é muito superior) para Linux RHEL, Centos e OEL.

Preparar o Linux para instalar o  Oracle RAC ou Clusterware pode ser simplificado utilizando a ajuda do Oracle Validated RMP.

Para ajudar verificar se você tem todos os pré-requisistos e pacotes necessários para a instalação do Oracle voce pode utilizar um especial RPM chamado oracle-validated.

Este RPM irá verificar se voce tem todos pré-requisitos,  RPMs necessários para instalação do Oracle  e ira configurar todos parametros de memoria e kernel corretamente.

Na instalação do Pacote oracle-validated  terá como dependencias os pacotes necessários para instalar o Oracle Software.

Para configurar os parametros de memoria , kernel e usuario você poderá executar um binario chamado oracle-validated-verify. (abaixo tem os exemplos).

Até recentemente , para poder usar o Oracle Validated era necessário ter o Suporte do Umbreakable Linux Network.

Agora esta disponivel para o publico em geral.
Donwload do Oracle Validated  para OEL5  aqui

Download do Oracle Validated para  OEL4 aqui

O seguinte documento contém detalhes a instalação do Oracle Validated  aqui.

Ver nota da Oracle Linux OS Installation with Reduced Set of Packages for Running Oracle Database Server [ID 728346.1]

Utilização:

Depois de Instalado o Oracle-Validated

Com o Usuario root execute o seguinte comando:

oracle-validate-verify

Após executar este comando o utilitario irá realizar as mudanças necessarias para o Oracle executar.

Voce pode rever as mudanças realizadas  verificando o arquivo.

more /var/log/oracle-validated/results/orakernel.log

Infelizmente ainda temos que configurar o arquivo /etc/pam.d/login adicionando as seguintes linhas.

vi /etc/pam.d/login
# adicionar se estiver faltando
session  required   /lib/security/pam_limits.so
session  required   pam_limits.so

Aproveite!!!