DBAGuard lhe dá as Boas Vindas

Bem-Vindo ao DataBase Guard, criado para dividir com a comunidade Oracle Brasileira todas as experiencias vividas pelo autor. Sintam-se em casa.

DBAGuard lhe dá as Boas Vindas

Bem-Vindo ao DataBase Guard, criado para dividir com a comunidade Oracle Brasileira todas as experiencias vividas pelo autor. Sintam-se em casa.

DBAGuard lhe dá as Boas Vindas

Bem-Vindo ao DataBase Guard, criado para dividir com a comunidade Oracle Brasileira todas as experiencias vividas pelo autor. Sintam-se em casa.

DBAGuard lhe dá as Boas Vindas

Bem-Vindo ao DataBase Guard, criado para dividir com a comunidade Oracle Brasileira todas as experiencias vividas pelo autor. Sintam-se em casa.

DBAGuard lhe dá as Boas Vindas

Bem-Vindo ao DataBase Guard, criado para dividir com a comunidade Oracle Brasileira todas as experiencias vividas pelo autor. Sintam-se em casa.

quarta-feira, 1 de julho de 2015

GUOB Tech Day 2015 - Se aproxima mais uma Edição


Olá Pessoal , como estão todos?

Estamos nos aproximando de mais uma edição deste evento de tecnologia que já é tradição para muitos de nossos profissionais Oracle do mercado de São Paulo e Brasil. Não deixem de aproveitar as facilidades em valores de inscrições realizadas antecipadamente. Este ano teremos a presença de nomes muito conhecidos pela comunidade Oracle mundial, tais como:


  • Alex Zaballa
  • Tim Hall
  • Francisco Alvarez
  • Gustavo Gonzalez
  • Kerry Osborne
  • Mike Dietrich
  • Debra Liley
Muitos dos nomes citados acima são autores de livros Oracle, levem seus livros caso queiram um autografo de alguns deles, será um prazer receber todos em mais um ano de GUOB TECHDAY.


Para maiores informações inscrevam-se no site do grupo e no evento, aproveitem as formas de pagamento antencipado:

GUOB Website

Vejo todos vocês por lá!!!

Abraço e Sucesso Sempre!!!

quinta-feira, 7 de maio de 2015

ADRCI - Como Otimizar a Utilização de Espaço Causado pelos Logs e Traces? - PARTE II





Olá pessoal estamos de volta para continuarmo nosso bate-papo sobre os tão famosos arquivos de log's do Oracle e suas implicações. 

Recapitulando um pouco, no primeiro artigo nós identificamos a estrutura dos arquivos gerados em nossos servidores, utilizamos um pouco de conceito do fabricante para entender exatemente do que se tratam os arquivos de log de diagnóstico e agora iremos entender melhor , quem são, como apaga-los e como controlar essa multiplicação de arquivos através do ADRCI

IDENTIFICANDO OS MAIORES DIRETÓRIOS DE LOGS.

É muito comum quando esses arquivos gerados exponencialmente e até então sem controle prévio nosso, começarem a gerar um certo desconforto para a administração, pois como são arquivos fisicos eles ocupam espaço, que por sua vez irão se acumulando e cada vez mais necessitando de mais espaço. DEVO GUARDA-LOS? Isso tudo depende, esses arquivos são mais utilizados para diagnosticar problemas com maior riqueza de detalhes ou então são solicitados pelo suporte Oracle para que possa identificar melhor qualquer eventual chamado que possamos necessitar abrir. Guarda-los depende só da politica de armazenamento de cada lugar, você pode muito bem gerar um arquivo do tipo TAR com todos os logs, compacta-los e guardar em fita de backup para depois remove-los, seria uma espécie de cópia de segurança caso fosse futuramente solicitado.

Eu no entanto removo sem backupea-los, pois não tenho um volume consideravel para poder mante-los por longos periodos em meu servidor, neste ambiente de teste até tenho pois não é transacional, mas com certeza muitos de vocês já tiveram problemas semelhantes de falta de espaço.

Vejam :





No meu caso tenho aqui o diretório de traces ocupando um espaço maior que os demais, utilizei o comando linux "du -sh *" que irá me mostrar de todos os diretórios o quanto cada um está consumindo. Notem que acima eu estou dentro do diretório de diagnostico do meu ambiente "$ORACLE_BASE/diag/rdbms/[db_name]/[instance_name]/". Pois bem, agora então vamos checar em como está nossa politica de retenção para este ambiente :

Não sei se alguns de vocês já teve a curiosidade ou sequer se perguntou se não havia uma forma de controlar o tempo de retenção destes arquivos, por padrão a Oracle determina que esses valores de SHORTP_POLICY e LONGP_POLICY tenham respectivamente 10 dias e 1 ano para os tipos.




QUAIS ARQUIVOS PERTENCEM A ESSES TIPOS?

Foi quando me deparei com essas informações que até então eram "grego" para mim, que fui buscar o conhecimento para entender melhor tudo isso que o comando "SHOW CONTROL" me mostrava, e descobri que :

LONGP_POLICY : é utilizada para expurgar arquivos de longa duração. Por padrão são 365 dias de armazenamento.

Esta politica é usada para os arquivos de :



  • ALERT
  • INCIDENT
  • SWEEP
  • STAGE
  • HM

SHORTP_POLICY  : claro que este é o oposto do anterior,são para os arquivos de menor duração.Padrão é  30 dias. Utilizada para os arquivos do tipo descritos abaixo :


  • TRACE
  • CDUMP
  • UTSCDMP
  • IPS
O que isso significa então? Significa que, se não forem alteradas as politicas os arquivos serão mantidos ali por dias meses e anos sem fim e sem o menor fundamento, pois não acredito que em dezembro de um ano qualquer alguem peça um log gerado em Janeiro daquele mesmo ano, muitissimo improvavel.

COMO FAÇO PARA ALTERAR ESSAS POLITICAS

Pois muito que bem, diante dessas informações e com respaldo do MOS ( My Oracle Support) apoiado na documentação oficial e nos DOC Id's de números :

975448.1
564269.1

Que podem ser encontrados na página do My Oracle Support, eu encontrei o comando para alteração, chama-se SET CONTROL, onde para aplica-lo você deve proceder da seguinte forma :

set control ( SHORTP_POLICY = dias de retenção)
set control (LONGP_POLICY = dias de retenção)

 Pronto, temos nossas politicas de retenção alteradas e aplicadas. E agora podemos nos preocupar com menos este problema, é claro que isso é administração pura de ambientes, nada além disso, sugiro que apliquem e monitorem, obviamente a remoção manual destes arquivos não gera prejuizos até então para o funcionamento do banco de dados, se você entrar no diretório de traces, de incident e de alert e remove-los simplesmente, isso não irá parar seu sistema. Contudo essa forma de administração é mais segura e mais eficaz, pois atacamos a causa do problema, sugiro á vocês que após isso façam um PURGE e acompanhem e vejam se o comportamento muda.

Obrigado á todos pela atenção, espero que tenham gostado e até a próxima.

SUCESSO Sempre!!!


quinta-feira, 26 de março de 2015

ADRCI - Como Otimizar a Utilização de Espaço Causado pelos Logs e Traces? - PARTE I

Olá como vocês estão? Espero que bem. Já a algum tempo que venho comentando com alguns amigos sobre o meu desejo de escrever sobre o ADRCI da Oracle, porém nunca me encontrei em uma situação que me desse vontade para tal, pois bem, hoje estou aqui para falar de um cenário que ocorreu comigo e que pode muito bem ocorrer com qualquer um de nós no dia-a-dia, ainda mais se estivermos administrando um ambiente que não fomos nós que criamos.

Tentarei neste post, mostrar á vocês a eficácia de se manter sob controle este aplicativo que gerencia os logs e arquivos de trace utilizado nos diagnósticos de muitos de nossos problemas corriqueiros. Vamos lá!

ADRCI - O que é?

É sempre de bom tom conceituar algo antes de iniciar, trata-se de uma interface do tipo command-line, onde é possivel gerenciar, remover ou visualizar conteúdo de arquivos gerados a todo momento pelos nossos bancos de dados ( Por Exemplo : Traces, Alert.log, Incident, e etc).

O ADRCI foi introduzido na versão Oracle Database 11g, é capaz de executar scripts a partir de sua linha de comando, assim como fazemos via SQL*Plus, também é possivel como foi dito acima gerenciar arquivos, mais quais são as categorias desses arquivos que podem ser gerenciados pelo ADRCI?

Atualmente a intenção da Oracle em usar o ADRCI, além de facilitar o gerenciamento dos arquivos, também criou uma espécie de ITIL dentro do próprio Banco de Dados, como assim? Sim , é isso mesmo pois o ADRCI trata problemas e incidentes, conceitos muito familiares para quem atua com ITIL.

Problemas : são aqueles cujo impacto é critico para o banco de dados, como por exemplo a geração de erros do tipo ORA-0600 ou ORA-07445 ou ainda o famoso ORA-4031

Incidente: os incidentes são tratados a parte e são gerados todas as vezes que temos muitos problemas recorrentes dentro do nosso banco, dai então é gerado um incidente e o mesmo deverá ser tratado no momento oportuno pelo DBA ou pelo administrador que estiver conduzindo o ambiente.

ESTRUTURA DO ADR

Abaixo veremos um schema de como é a hierarquia de pastas e diretórios utilizados pelo ADR :






Bem para maiores informações sobre o ADR e suas estruturas podemos utilizar a documentação oficial que é bastante esclarecedora sobre o assunto, vocês podem encontra-la no seguinte link abaixo :

ADRCI-Doc

O CENÁRIO

Meu problema foi gerado graças a um pequeno descuido com relação a não observância no que diz respeito aos limites do sistema operacional no tocante espaço, por exemplo os meus arquivos de traces e logs eram gerados indiscriminadamente dentro do meu diretório, sem qualquer politica adequada para minha realidade de espaço disponível para tal.

Foi onde me deparei com o problema, pois a ferramenta de monitoração do meu ambiente, de tempos em tempos me informava que eu estava com pouco espaço justamente na ORACLE_HOME do banco, onde também ficam localizados os arquivos de de traces e logs :









É claro que no meu caso aqui poderiamos até pensar no seguinte, como estamos trabalhando em LVM, se eu tiver espaço para expandir meu disco sem problemas correto? Errado. Isso é uma idéia equivocada, pois gera desperdicio de recurso de disco, pois se cada vez que eu obtiver um erro por falta de espaço eu incrementar meu file system mais e mais, só estarei alimentando um monstro e atacando o problema e não a causa.

É obvio que no meu ambiente controlado e não produtivo, a geração de logs é infinitamente menor do que a de um ambiente transacional , onde temos a todo momento a aplicação e os desenvolvedores testando suas queries e seus processos até chegarem a um denominador comum. Enquanto isso nos bastidores nos arquivos são gerados e consumindo cada vez mais espaço.

O QUE FAZER ENTÃO?

Dentro do diretório DIAG mostrado na figura acima há outros demais subdiretórios contendo os arquivos propriamente ditos :





No nosso ambiente o vilão é esta basta denominada RDBMS, onde ficam outros demais subdiretórios que contém efetivamente cada tipo de arquivo :





Temos então identificados nossos vilões de consumo, onde via de regra serão sempre os mesmos a consumirem mais e mais espaço, que são os diretórios denominados ALERT e TRACE, os de INCIDENT costumam dar trabalho também, mais são infinitamente menores que os demais.

Bem, para não me demorar muito e ficar muito extenso o post, quebrarei em mais um pedaço para apresentar á vocês a solução para controlar a geração dos logs e também a limpeza dos mesmos.

Obrigado por acompanharem o canal, espero que todos tenham gostado até aqui. Sucesso SEMPRE!!!





sexta-feira, 27 de fevereiro de 2015

Atualizando seu Oracle RAC 11.2.0.2 para 11.2.0.3 com aumento de Filesystem - PARTE III


Olá pessoal, como estão todos? Espero que bem, há muito tempo não falo com vocês, mas voltei para terminar aquele artigo sobre atualização do Oracle RAC, espero que apreciem o trabalho em conjunto com o meu amigo Thiago Silva. Divirtam-se!!!

ATUALIZANDO BINÁRIOS


Demorei para escrever essa ultima parte do artigo, é que esses últimos meses estava super corridor, mas vamos para o que interessa terminar essa Terceira e última parte do artigo. Antes de iniciar a atualização do Oracle, vamos aplicar o bundle patch no binário do Oracle 11.2.0.2 com utilitário OPacth.

[oracle@ora-rac01 binarios]$ srvctl stop database -d dath
[oracle@ora-rac01 binarios]$ srvctl status database -d dath
A instância dath1 não está em execução no nó ora-rac01
A instância dath2 não está em execução no nó ora-rac02
  [root@ora-rac02 binarios]# ls
16459322  16619893  bundle.xml p16742320_112020_Linux-x86-64.zip  README.html README.txt
[root@ora-rac02 binarios]# opatch auto -oh /u01/app/oracle/product/11.2.0.2/db_1 -olderver
Executing /u01/app/11.2.0.2/grid/perl/bin/perl /u01/app/oracle/product/11.2.0.2/db_1/OPatch/crs/patch11202.pl -patchdir / -patchn binarios -oh /u01/app/oracle/product/11.2.0.2/db_1 -paramfile /u01/app/11.2.0.2/grid/crs/install/crsconfig_params
INC is /binarios/16459322/files/crs/install /u01/app/11.2.0.2/grid/crs/install /u01/app/11.2.0.2/grid/perl/lib/5.10.0/x86_64-linux-thread-multi /u01/app/11.2.0.2/grid/perl/lib/5.10.0 /u01/app/11.2.0.2/grid/perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /u01/app/11.2.0.2/grid/perl/lib/site_perl/5.10.0 /u01/app/11.2.0.2/grid/perl/lib/5.10.0/x86_64-linux-thread-multi /u01/app/11.2.0.2/grid/perl/lib/5.10.0/x86_64-linux-thread-multi /u01/app/11.2.0.2/grid/perl/lib/5.10.0 /u01/app/11.2.0.2/grid/perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /u01/app/11.2.0.2/grid/perl/lib/site_perl/5.10.0 /u01/app/11.2.0.2/grid/perl/lib/site_perl . 
opatch auto log file location is /u01/app/oracle/product/11.2.0.2/db_1/OPatch/crs/../../cfgtoollogs/opatchauto2014-06-30_01-25-21.log
Detected Oracle Clusterware install
Using configuration parameter file: /u01/app/11.2.0.2/grid/crs/install/crsconfig_params
OPatch  is bundled with OCM, Enter the absolute OCM response file path:
/u01/app/11.2.0.2/grid/OPatch/ocm/bin/ocm.rsp
patch //binarios/16459322/custom/server/16459322  apply successful for home  /u01/app/oracle/product/11.2.0.2/db_1
patch //binarios/16619893  apply successful for home  /u01/app/oracle/product/11.2.0.2/db_1
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT
/u01/app/oracle/cfgtoollogs/catbundle/catbundle_PSU_DATH_APPLY_2014Jun30_01_44_15.log

O Bundle patch deverá ser aplicado em todos os nó do Rac, após aplicar o patch no último nó, executei o script catbundle.sql no meu último nó do Rac, conforme saída acima. Após a aplicação do Bundle Patch, fiz um backup via RMAN também.
[oracle@ora-rac01 ~]$ rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Sun Mar 9 15:03:42 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: DATH (DBID=3788767579)
RMAN> run {
2> allocate channel d1 type disk;
3> backup database tag 'BEFORE_UPGRADE';
4> backup current controlfile tag 'BK_CF_BEFORE_UPGRADE';
5> release channel d1;
6> }
using target database control file instead of recovery catalog
allocated channel: d1
channel d1: SID=55 instance=dath2 device type=DISK
Starting backup at 09/03/2014 15:04:47
channel d1: starting full datafile backup set
channel d1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA/dath/datafile/system.256.841354699
input datafile file number=00002 name=+DATA/dath/datafile/sysaux.257.841354701
input datafile file number=00005 name=+DATA/dath/datafile/example.264.841354867
input datafile file number=00003 name=+DATA/dath/datafile/undotbs1.258.841354703
input datafile file number=00006 name=+DATA/dath/datafile/undotbs2.265.841355319
input datafile file number=00004 name=+DATA/dath/datafile/users.259.841354705
channel d1: starting piece 1 at 09/03/2014 15:04:47
channel d1: finished piece 1 at 09/03/2014 15:05:02
piece handle=+RECO/dath/backupset/2014_03_09/nnndf0_before_upgrade_0.292.841763087 tag=BEFORE_UPGRADE comment=NONE
channel d1: backup set complete, elapsed time: 00:00:15
Finished backup at 09/03/2014 15:05:02
Starting backup at 09/03/2014 15:05:03
channel d1: starting full datafile backup set
channel d1: specifying datafile(s) in backup set
including current control file in backup set
channel d1: starting piece 1 at 09/03/2014 15:05:04
channel d1: finished piece 1 at 09/03/2014 15:05:05
piece handle=+RECO/dath/backupset/2014_03_09/ncnnf0_bk_cf_before_upgrade_0.295.841763105 tag=BK_CF_BEFORE_UPGRADE comment=NONE
channel d1: backup set complete, elapsed time: 00:00:01
Finished backup at 09/03/2014 15:05:05
Starting Control File and SPFILE Autobackup at 09/03/2014 15:05:05
piece handle=+RECO/dath/autobackup/2014_03_09/s_841763105.296.841763105 comment=NONE
Finished Control File and SPFILE Autobackup at 09/03/2014 15:05:06
released channel: d1
RMAN> list backup of database summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- ------------------- ------- ------- ---------- ---
5 B F A DISK 04/03/2014 22:19:09 1 1 YES BKP_FULL
10 B F A DISK 09/03/2014 15:04:58 1 1 NO BEFORE_UPGRADE
RMAN>
Agora vamos para instalação do Oracle 11.2.0.3, antes de iniciar  criei o diretório de destino dos binários da release 11.2.0.3/db_1.
[root@ora-rac01 /]# mkdir –p /u01/app/oracle/product/11.2.0.3/db_1
[root@ora-rac01 /]# chown –R oracle:oinstall 11.2.0.3/db_1

Em seguida alterei o meu bash_profile para carregar o novo caminho da variável ORACLE_HOME, depois descompactei os binário do Oracle e iniciei o instalador.

[oracle@ora-rac01 ~]$ source dath.env
[oracle@ora-rac01 ~]$ echo $ORACLE_BASE
/u01/app/oracle
[oracle@ora-rac01 ~]$ echo $ORACLE_HOME
/u01/app/oracle/product/11.2.0.3/db_1
[oracle@ora-rac01 binarios]$ ls -lthor
total 2,4G
-rwxr-xr-x 1 oracle 1,3G Mar 9 15:10 p10404530_112030_Linux-x86-64_1of7.zip
-rwxr-xr-x 1 oracle 1,1G Mar 9 15:11 p10404530_112030_Linux-x86-64_2of7.zip
[oracle@ora-rac01 binarios]$ unzip p10404530_112030_Linux-x86-64_1of7.zip
[oracle@ora-rac01 binarios]$ unzip p10404530_112030_Linux-x86-64_2of7.zip
[oracle@ora-rac01 binarios]$ ls -lthor
total 2,4G
drwxr-xr-x 8 oracle 4,0K Set 22 2011 database
-rwxr-xr-x 1 oracle 1,3G Mar 9 15:10 p10404530_112030_Linux-x86-64_1of7.zip
-rwxr-xr-x 1 oracle 1,1G Mar 9 15:11 p10404530_112030_Linux-x86-64_2of7.zip
[oracle@ora-rac01 binarios]$ cd database/
[oracle@ora-rac01 database]$ ls
doc install readme.html response rpm runInstaller sshsetup stage welcome.html
[oracle@ora-rac01 database]$ ./runInstaller










root@ora-rac01 ~]# cd /u01/app/oracle/product/11.2.0.3/db_1/
[root@ora-rac01 db_1]# ./root.sh
Performing root user operation for Oracle 11g
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /u01/app/oracle/product/11.2.0.3/db_1
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Finished product-specific root actions.
[root@ora-rac01 db_1]#

[root@ora-rac02 ~]# cd /u01/app/oracle/product/11.2.0.3/db_1/
[root@ora-rac02 db_1]# ./root.sh
Performing root user operation for Oracle 11g
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /u01/app/oracle/product/11.2.0.3/db_1
Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Finished product-specific root actions.

Como vocês mesmo visualizaram, instalei somente o software de banco de dados e não iniciei ainda o upgrade do banco. No próximo passo vou executar o upgrade do banco de dados manualmente, ou seja efetuaremos via script.
 [oracle@ora-rac01 dbs]$ ls
hc_dath1.dat  hc_DBUA0.dat  initdath1.ora  init.ora  orapwdath1  snapcf_dath1.f
[oracle@ora-rac01 dbs]$ cp orapwdath1 /u01/app/oracle/product/11.2.0.3/db_1/dbs/
[oracle@ora-rac01 dbs]$ cd /u01/app/oracle/product/11.2.0.3/db_1/dbs/
[oracle@ora-rac01 dbs]$ ls
init.ora  orapwdath1
[oracle@ora-rac01 dbs]$

[oracle@ora-rac01 dbs]$ cd /u01/app/oracle/product/11.2.0.2/db_1/network/admin/
[oracle@ora-rac01 admin]$ ls
samples  shrept.lst  tnsnames.ora
[oracle@ora-rac01 admin]$ cp tnsnames.ora /u01/app/oracle/product/11.2.0.3/db_1/network/admin/
[oracle@ora-rac01 admin]$ cd /u01/app/oracle/product/11.2.0.3/db_1/network/admin/
[oracle@ora-rac01 admin]$ ls
samples  shrept.lst  tnsnames.ora
[oracle@ora-rac01 admin]$ cat tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.2.0.2/db_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.

DATH =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora-rac-scan)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = dath)
    )
  )


SQL> show parameter spfile

NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile     string +DATA/dath/spfiledath.ora
SQL> create pfile='/home/oracle/initdath1.ora' from spfile;

File created.

SQL>

#*.cluster_database=true
*.compatible='11.2.0.0.0'
*.control_files='+DATA/dath/controlfile/current.261.850748285','+DATA/dath/controlfile/current.260.850748285'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_domain=''
*.db_name='dath'
*.db_recovery_file_dest_size=4227858432
*.db_recovery_file_dest='+RECO'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dathXDB)'
#dath1.instance_number=1
#dath2.instance_number=2
*.nls_language='BRAZILIAN PORTUGUESE'
*.nls_territory='BRAZIL'
*.open_cursors=300
*.pga_aggregate_target=104857600
*.processes=200
*.remote_listener='ora-rac-scan:1521'
*.remote_login_passwordfile='exclusive'
*.sessions=225
*.sga_target=524288000
#dath2.thread=2
#dath1.thread=1
#dath2.undo_tablespace='UNDOTBS2'


[oracle@ora-rac01 ~]$ srvctl stop database -d dath -o immediate

[grid@ora-rac01 ~]$ cd $ORACLE_HOME/bin
[grid@ora-rac01 bin]$ pwd
/u01/app/11.2.0.3/grid/bin
[grid@ora-rac01 bin]$ ./setasmgidwrap o=/u01/app/oracle/product/11.2.0.3/db_1/bin/oracle
[grid@ora-rac01 bin]$ cd /u01/app/oracle/product/11.2.0.3/db_1/bin/
[grid@ora-rac01 bin]$ ls -l oracle
-rwsr-s--x 1 oracle asmadmin 232399431 Sep 21 02:54 oracle
[grid@ora-rac01 bin]$


SQL> startup upgrade pfile='/home/oracle/initdath1.ora'
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size     2235208 bytes
Variable Size   272630968 bytes
Database Buffers   788529152 bytes
Redo Buffers     5541888 bytes
Database mounted.
Database opened.
SQL>

old   2:    IF '&&mig_file' = '1102000' THEN
new   2:    IF '1102000' = '1102000' THEN

PL/SQL procedure successfully completed.

SQL> drop version_script;   -- no longer needed
  2
SQL> SELECT :utl_name FROM DUAL;




1 row selected.

SQL> @@&utl_file
SQL> Rem
SQL> Rem $Header: catupshd.sql 12-jul-2007.07:16:44 rburns Exp $
SQL> Rem
SQL> Rem catupshd.sql
SQL> Rem
SQL> Rem Copyright (c) 2007, Oracle. All rights reserved.
SQL> Rem
SQL> Rem    NAME
SQL> Rem      catupshd.sql - CATalog UPgrade SHutDown
SQL> Rem
SQL> Rem    DESCRIPTION
SQL> Rem      This script shuts down the database at the conclusion of
SQL> Rem      upgrades that do not run utlmmig.sql, which also does a shutdown.
SQL> Rem
SQL> Rem    NOTES
SQL> Rem      Invoked from catupend.sql
SQL> Rem
SQL> Rem    MODIFIED   (MM/DD/YY)
SQL> Rem    rburns      07/12/07 - final upgrade shutdown
SQL> Rem    rburns      07/12/07 - Created
SQL> Rem
SQL>
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL>
SQL> DOC
DOC>#######################################################################
DOC>#######################################################################
DOC>
DOC>   The above sql script is the final step of the upgrade. Please
DOC>   review any errors in the spool log file. If there are any errors in
DOC>   the spool file, consult the Oracle Database Upgrade Guide for
DOC>   troubleshooting recommendations.
DOC>
DOC>   Next restart for normal operation, and then run utlrp.sql to
DOC>   recompile any invalid application objects.
DOC>
DOC>   If the source database had an older time zone version prior to
DOC>   upgrade, then please run the DBMS_DST package.  DBMS_DST will upgrade
DOC>   TIMESTAMP WITH TIME ZONE data to use the latest time zone file shipped
DOC>   with Oracle.
DOC>
DOC>#######################################################################
DOC>#######################################################################
DOC>#
SQL>
SQL> Rem Set errorlogging off
SQL> SET ERRORLOGGING OFF;
SQL>
SQL> REM END OF CATUPGRD.SQL
SQL>
SQL> REM bug 12337546 - Exit current sqlplus session at end of catupgrd.sql.
SQL> REM                This forces user to start a new sqlplus session in order
SQL> REM                to connect to the upgraded db.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options



SQL> @?/rdbms/admin/utlu112s.sql
.
Oracle Database 11.2 Post-Upgrade Status Tool 09-21-2014 05:09:33
.
Component Current      Version Elapsed Time
Name Status     Number HH:MM:SS
.
Oracle Server
.   VALID      11.2.0.3.0  00:24:19
JServer JAVA Virtual Machine
.   VALID      11.2.0.3.0  00:04:53
Oracle Real Application Clusters
.   VALID      11.2.0.3.0  00:00:01
Oracle Workspace Manager
.   VALID      11.2.0.3.0  00:00:46
OLAP Analytic Workspace
.   VALID      11.2.0.3.0  00:00:26
OLAP Catalog
.   VALID      11.2.0.3.0  00:01:07
Oracle OLAP API
.   VALID      11.2.0.3.0  00:00:34
Oracle Enterprise Manager
.   VALID      11.2.0.3.0  00:04:04
Oracle XDK
.   VALID      11.2.0.3.0  00:01:11
Oracle Text
.   VALID      11.2.0.3.0  00:00:46
Oracle XML Database
.   VALID      11.2.0.3.0  00:04:04
Oracle Database Java Packages
.   VALID      11.2.0.3.0  00:00:27
Oracle Multimedia
.   VALID      11.2.0.3.0  00:04:54
Spatial
.   VALID      11.2.0.3.0  00:03:06
Oracle Expression Filter
.   VALID      11.2.0.3.0  00:00:14
Oracle Rules Manager
.   VALID      11.2.0.3.0  00:00:11
Oracle Application Express
.   VALID     3.2.1.00.12
Gathering Statistics
. 00:02:55
Total Upgrade Time: 00:54:09

PL/SQL procedure successfully completed.

SQL>



SQL> @?/rdbms/admin/catuppst.sql

Generating apply and rollback scripts...
Check the following file for errors:
/u01/app/oracle/cfgtoollogs/catbundle/catbundle_PSU_DATH_GENERATE_2014Sep21_05_11_35.log
Apply script: /u01/app/oracle/product/11.2.0.3/db_1/rdbms/admin/catbundle_PSU_DATH_APPLY.sql
Rollback script: /u01/app/oracle/product/11.2.0.3/db_1/rdbms/admin/catbundle_PSU_DATH_ROLLBACK.sql

PL/SQL procedure successfully completed.

Executing script file...




SQL> COLUMN spool_file NEW_VALUE spool_file NOPRINT
SQL> SELECT '/u01/app/oracle/cfgtoollogs/catbundle/' || 'catbundle_PSU_' || name || '_APPLY_' || TO_CHAR(SYSDATE, 'YYYYMonDD_hh24_mi_ss', 'NLS_DATE_LANGUAGE=''AMERICAN''') || '.log' AS spool_file FROM v$database;




SQL> SPOOL &spool_file
SQL> exec dbms_registry.set_session_namespace('SERVER')

PL/SQL procedure successfully completed.

SQL> ALTER SESSION SET current_schema = SYS;

Session altered.

SQL> PROMPT Updating registry...
Updating registry...
SQL> INSERT INTO registry$history
  2    (action_time, action,
  3     namespace, version, id,
  4     bundle_series, comments)
  5  VALUES
  6    (SYSTIMESTAMP, 'APPLY',
  7     SYS_CONTEXT('REGISTRY$CTX','NAMESPACE'),
  8     '11.2.0.3',
  9     0,
 10     'PSU',
 11     'Patchset 11.2.0.2.0');

1 row created.

SQL> COMMIT;

Commit complete.

SQL> SPOOL off
SQL> SET echo off
Check the following log file for errors:
/u01/app/oracle/cfgtoollogs/catbundle/catbundle_PSU_DATH_APPLY_2014Sep21_05_11_37.log
SQL>



SQL> spool upgrade3.log
SQL> @?/rdbms/admin/utlrp.sql

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN  2014-09-21 05:14:47

DOC>   The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC>   objects in the database. Recompilation time is proportional to the
DOC>   number of invalid objects in the database, so this command may take
DOC>   a long time to execute on a database with a large number of invalid
DOC>   objects.
DOC>
DOC>   Use the following queries to track recompilation progress:
DOC>
DOC>   1. Query returning the number of invalid objects remaining. This
DOC>   number should decrease with time.
DOC>     SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC>   2. Query returning the number of objects compiled so far. This number
DOC>   should increase with time.
DOC>     SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC>   This script automatically chooses serial or parallel recompilation
DOC>   based on the number of CPUs available (parameter cpu_count) multiplied
DOC>   by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC>   On RAC, this number is added across all RAC nodes.
DOC>
DOC>   UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC>   recompilation. Jobs are created without instance affinity so that they
DOC>   can migrate across RAC nodes. Use the following queries to verify
DOC>   whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC>   1. Query showing jobs created by UTL_RECOMP
DOC>     SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC>   2. Query showing UTL_RECOMP jobs that are running
DOC>     SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#


PL/SQL procedure successfully completed.


TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_END  2014-09-21 05:34:14

DOC> The following query reports the number of objects that have compiled
DOC> with errors (objects that compile with errors have status set to 3 in
DOC> obj$). If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#

OBJECTS WITH ERRORS
-------------------
  0

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
---------------------------
  0


Function created.


PL/SQL procedure successfully completed.


Function dropped.


PL/SQL procedure successfully completed.

SQL> SQL>


[oracle@ora-rac01 ~]$ srvctl remove database -d dath
Remover o banco de dados dath? (y/[n]) y
[oracle@ora-rac01 ~]$

SQL> show parameter spfile

NAME     TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile     string
SQL> create spfile='+DATA/DATH/spfiledath.ora' from pfile='/home/oracle/initdath1.ora';

File created.

[oracle@ora-rac01 dbs]$ srvctl add database -d dath -o $ORACLE_HOME -y AUTOMATIC -a "DATA,RECO"
[oracle@ora-rac01 dbs]$ srvctl add instance -d dath -i dath1 -n ora-rac01
[oracle@ora-rac01 dbs]$ srvctl add instance -d dath -i dath2 -n ora-rac02
[oracle@ora-rac01 ~]$ srvctl start database -d dath -o open
[oracle@ora-rac01 ~]$ srvctl status database -d dath
A instância dath1 está em execução no nó ora-rac01
A instância dath2 está em execução no nó ora-rac02

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SQL> select instance_name, status from gv$instance;

INSTANCE_NAME STATUS
---------------- ------------
dath1 OPEN
dath2 OPEN

Bem é isso, finalizamos nossa atualização do ambiente de Cluster Oracle RAC 11gR2, saimos da release 11.2.0.2 para 11.2.0.3, espero que tenham apreciado esse laboratório e que ele seja util para todos vocês, obrigado mais uma vez pela paciencia.
Por Thiago Silva.
 
PessoALL, espero que tenham gostado, divirtam-se experimentando essa atualização em seus laboratórios, obrigado ao meu amigo Thiago pela honra de aceitar escrever em meu espaço, espero que seja util. SUCESSO SEMPRE!!!




.

segunda-feira, 5 de maio de 2014

O que precisamos saber sobre incidências de "FTS" ( Full-Table-Scan) em nosso Banco de Dados

INTRODUÇÃO :

Olá á todos? Como estão? Bem, eu estava arrumando alguns livros de minha coleção quando me deparei com um assunto que eu particularmente sempre vivenciei nas empresas por onde passei.

As ocorrências cotidianas de "full-table-scan", eram e são situações muito atuais em qualquer base de dados transacional (OLTP) ou até mesmo em bases DW ( DataWarehousing).

Tudo isso se deve ao fato de que os FTS ( Full-Table-Scans), não são erros encontrados no banco de dados, nem tão pouco tratam-se sempre de vilões em nossas bases, é preciso compreeder e analisar os aspectos que envolvem um evento de full table scan antes de diagnostica-lo como problema da sua query ou até mesmo pelo nível elevado de incidências no seu banco de dados, um problema para sua Base.

Mas antes de prosseguirmos é primordial um breve conceito então, sobre o que viria a ser um FTS?

O QUE É UM FULL-TABLE-SCAN?

Conceito : Trata-se de um método de leitura dos dados das tabelas, que também é conhecido como leitura SEQUENCIAL, onde ocorre uma validação por parte do otimizador do banco de dados ao ler o objeto do tipo tabela de maneira completa, analisando linha por linha e coluna por coluna para tal. É uma operação muito custosa para o banco de dados em si, pois demanda uma enorme quantidade de I/O para ser executada, e com isso acarretam como consequência principal em muitos casos, a queda na performance de algumas consultas. A ausência de indices adequados, bem como a presença de joins entre duas ou mais tabelas, pode sim acarretar essa situação como reflexo, por isso é necessário a analíse minuciosa do problema.

DEVO EVITAR OS FTS's EM MEU BANCO DE DADOS?

Sim e Não. Positivamente, é necessário que todo DBA tenha uma administração pró-ativa de sua base de dados, seja através de ferramentas de monitoramento próprietárias, scripts manuais ou qualquer outro tipo de controle de atividades das bases de dados, sobretudo no que diz respeito a consumo, sejam eles de CPU, I/O ou Memória. Negativamente é impossível que se evite os FTS's em 100% em uma base de dados, claro que um modelo bem delineado, com uma intervenção minima em termos dde alterações de estrutura de tabelas ajudaria muito, mais sabemos que por conta da real necessidade de inovação das aplicações, isso é HUMANAMENTE impossível de ter.

O QUE DEVEMOS FAZER ENTÃO?

Pimeiramente instruir a sua equipe de desenvolvimento, em conjunto com um AD ( Administrador de Dados), a criar uma politica interna de discussão sobre as alterações e não faze-las a qualquer tempo e de qualquer forma. É preciso que haja uma análise de impacto dessas alterações realizadas no banco de dados.

Relacionei baseando-se no que já vi por ai nas empresas, aspectos que julgo serem importantes para esse tipo de situação :

- planos de execuções;
- analise da volumetria da tabela;
- analíse sob a possiblidade da criação de um indice;
- analíse sobre a criação de um cluster ou tabela em cache de acordo com o tamanho;

Essas pequenas medidas, por si só já ajudariam em muito, é claro que como citei acima, um modelo bem elaborado por si só é muito eficiente. Entretando após o advento do ASM ( Automatic Storage Management) e também do nosso mais novo aliado as máquinas EXADATA Database Machine, com seus Database Storages, que possuem inteligencia própria para trabalhar as estruturas menóres do banco ( blocos de dados) tudo isso ficou meio que de lado. É raro ver um DBA hoje em dia usar o TKPROF para analisar o que quer que seja, a primeira opção em caso de encontrar um FTS's é ir logo ou rodando um ANALYZE TABLE/DBMS_STATS ou então sair criando indices nos campos para tentar melhorar.

Ambas ações acima descritas não estão de todo equivocadas, mas devem serem realizadas com cautela, usando um relatório de AWR por exemplo para identificação com precisão das potênciais query's com problemas, ou até mesmo utilizar a fantastica ferramenta do Oracle Cloud Control 12c e até o bom e velho amigo Oracle GRID CONTROL.

QUANDO OCORRE UM FTS's?

De acordo com a Oracle, uma tabela que retorne 40% de suas linhas em caso de serem ordenadas ou 7% de suas linhas em caso de não-ordenadas, levando em conta a chave do indice existente descrita na coluna clustering_factor da visão dba_indexes, esta consulta em si poderá ser re-organizada para um uso eficiente d eum indice novo ou já existente ao invés de usar um full-table-scan.


ALL_INDEXES

ALL_INDEXES describes the indexes on the tables accessible to the current user. To gather statistics for this view and the related views DBA_INDEXES andUSER_INDEXES, use the SQL ANALYZE statement.
Related Views
  • DBA_INDEXES describes all indexes in the database.
  • USER_INDEXES describes the indexes owned by the current user. This view does not display the OWNER column.
Note:
Column names followed by an asterisk are populated only if you collect statistics on the index using the ANALYZE statement or the DBMS_STATS package.
ColumnDatatypeNULLDescription
OWNERVARCHAR2(30)NOT NULLOwner of the index
INDEX_NAMEVARCHAR2(30)NOT NULLName of the index
INDEX_TYPEVARCHAR2(27) Type of the index:
  • NORMAL
  • BITMAP
  • FUNCTION-BASED NORMAL
  • FUNCTION-BASED BITMAP
  • DOMAIN
TABLE_OWNERVARCHAR2(30)NOT NULLOwner of the indexed object
TABLE_NAMEVARCHAR2(30)NOT NULLName of the indexed object
TABLE_TYPECHAR(5) Type of the indexed object (for example, TABLECLUSTER)
UNIQUENESSVARCHAR2(9) Indicates whether the index is UNIQUE or NONUNIQUE
COMPRESSIONVARCHAR2(8) Indicates whether index compression is enabled (ENABLED) or not (DISABLED)
PREFIX_LENGTHNUMBER Number of columns in the prefix of the compression key
TABLESPACE_NAMEVARCHAR2(30) Name of the tablespace containing the index
INI_TRANSNUMBER Initial number of transactions
MAX_TRANSNUMBER Maximum number of transactions
INITIAL_EXTENTNUMBER Size of the initial extent
NEXT_EXTENTNUMBER Size of secondary extents
MIN_EXTENTSNUMBER Minimum number of extents allowed in the segment
MAX_EXTENTSNUMBER Maximum number of extents allowed in the segment
PCT_INCREASENUMBER Percentage increase in extent size
PCT_THRESHOLDNUMBER Threshold percentage of block space allowed per index entry
INCLUDE_COLUMNNUMBER Column ID of the last column to be included in index-organized table primary key (non-overflow) index. This column maps to theCOLUMN_ID column of the *_TAB_COLUMNS data dictionary views.
FREELISTSNUMBER Number of process freelists allocated to this segment
FREELIST_GROUPSNUMBER Number of freelist groups allocated to this segment
PCT_FREENUMBER Minimum percentage of free space in a block
LOGGINGVARCHAR2(3) Logging information
BLEVEL*NUMBER B*-Tree level: depth of the index from its root block to its leaf blocks. A depth of 0 indicates that the root block and leaf block are the same.
LEAF_BLOCKS*NUMBER Number of leaf blocks in the index
DISTINCT_KEYS*NUMBER Number of distinct indexed values. For indexes that enforce UNIQUEand PRIMARY KEY constraints, this value is the same as the number of rows in the table (USER_TABLES.NUM_ROWS)
AVG_LEAF_BLOCKS_PER_KEY*NUMBER Average number of leaf blocks in which each distinct value in the index appears, rounded to the nearest integer. For indexes that enforce UNIQUE and PRIMARY KEY constraints, this value is always1.
AVG_DATA_BLOCKS_PER_KEY*NUMBER Average number of data blocks in the table that are pointed to by a distinct value in the index rounded to the nearest integer. This statistic is the average number of data blocks that contain rows that contain a given value for the indexed columns.
CLUSTERING_FACTOR*NUMBER Indicates the amount of order of the rows in the table based on the values of the index.
  • If the value is near the number of blocks, then the table is very well ordered. In this case, the index entries in a single leaf block tend to point to rows in the same data blocks.
  • If the value is near the number of rows, then the table is very randomly ordered. In this case, it is unlikely that index entries in the same leaf block point to rows in the same data blocks.
For bitmap indexes, this column is not applicable and is not used.
STATUSVARCHAR2(8) Indicates whether a nonpartitioned index is VALID or UNUSABLE
NUM_ROWSNUMBER Number of rows in the index
SAMPLE_SIZENUMBER Size of the sample used to analyze the index
LAST_ANALYZEDDATE Date on which this index was most recently analyzed
DEGREEVARCHAR2(40) Number of threads per instance for scanning the index
INSTANCESVARCHAR2(40) Number of instances across which the indexes to be scanned
PARTITIONEDVARCHAR2(3) Indicates whether the index is partitioned (YES) or not (NO)
TEMPORARYVARCHAR2(1) Indicates whether the index is on a temporary table
GENERATEDVARCHAR2(1) Indicates whether the name of the index is system generated (Y) or not (N)
SECONDARYVARCHAR2(1) Indicates whether the index is a secondary object created by theODCIIndexCreate method of the Oracle Data Cartridge (Y) or not (N)
BUFFER_POOLVARCHAR2(7) Name of the default buffer pool to be used for the index blocks
USER_STATSVARCHAR2(3) Indicates whether statistics were entered directly by the user (YES) or not (NO)
DURATIONVARCHAR2(15) Indicates the duration of a temporary table:
  • SYS$SESSION - Rows are preserved for the duration of the session
  • SYS$TRANSACTION - Rows are deleted after COMMIT
Null for a permanent table
PCT_DIRECT_ACCESSNUMBER For a secondary index on an index-organized table, the percentage of rows with VALID guess
ITYP_OWNERVARCHAR2(30) For a domain index, the owner of the indextype
ITYP_NAMEVARCHAR2(30) For a domain index, the name of the indextype
PARAMETERSVARCHAR2(1000) For a domain index, the parameter string
GLOBAL_STATSVARCHAR2(3) For partitioned indexes, indicates whether statistics were collected by analyzing the index as a whole (YES) or were estimated from statistics on underlying index partitions and subpartitions (NO)
DOMIDX_STATUSVARCHAR2(12) Status of the domain index:
  • NULL - Index is not a domain index
  • VALID - Index is a valid domain index
  • IDXTYP_INVLD - Indextype of the domain index is invalid
DOMIDX_OPSTATUSVARCHAR2(6) Status of the operation on the domain index:
  • NULL - Index is not a domain index
  • VALID - Operation performed without errors
  • FAILED - Operation failed with an error
FUNCIDX_STATUSVARCHAR2(8) Status of a function-based index:
  • NULL - Index is not a function-based index
  • ENABLED - Function-based index is enabled
  • DISABLED - Function-based index is disabled
JOIN_INDEXVARCHAR2(3) Indicates whether the index is a join index (YES) or not (NO)
IOT_REDUNDANT_PKEY_ELIMVARCHAR2(3) Indicates whether redundant primary key columns are eliminated from secondary indexes on index-organized tables (YES) or not (NO)
DROPPEDVARCHAR2(3) Indicates whether the index has been dropped and is in the recycle bin (YES) or not (NO); null for partitioned tables
Mas não são somente esses fatores que impactam neste caso, a analíse sobre essa situação deve ser bem mais criteriosa, a criação de indices ajudara? SIM, e muito, principalmente se eles forem baseados em funções que são utilizadas na query principal em algum momento. Devemos ter muito cuidado ao lidar com FT's, só a criação de novos indices não basta, após isso é primordial que façamos um estudo correlacionando a quantidade de I/O Lógicos contra as Leituras Consistentes ( Consistents Gets) e cruzando com o custo utilizado para as situações de Full Table Scan.

Notadamente todos nós sabemos que uma leitura de uma tabela em CACHE é muito mais eficiente e mais rápida do que um acesso á disco, deixemos de lado por enquanto a questão do software de inteligência do EXADATA Storage Server, e foquemos nas bases de dados em hardwares normais que não possuem essa arquitetura. Se nós conseguirmos colocar a tabela em questão em memória, seja "pinando" em memória ou até mesmo alocando-a em um POOL de Memória mais robusto (16k,32k ou 64k) em nosso Buffer_Pool, com toda certeza teremos uma eficiencia tamanha neste tempo de resposta, e ainda podemos contar também com o SSD em alguns casos.

Uma solução abordada por alguns DBA's, é a utilização do Oracle Parallel Query, para dar uma espécie de fôlego a mais para as tarefas de Scans, mais isso também implica no aumento do LOAD da CPU do ambiente onde é utilizado, é necessário ficar de olho.

CONCLUSÃO : é importante que todo DBA fique atento as periodicidades de execuções de FTs's em suas bases de dados, assim evitam-se maiores dores de cabeças com essa problemática. É preciso também que haja um trabalho conjunto de desenvolvimento e banco de dados neste ponto, para que a modelagem dos dados e das estruturas e co-relacionamentos não sejam prejudicados nem em suas raizes quanto em suas dependências. Vale lembrar que não adianta apenas apelar para as novas tecnologias existentes, elas são extremamente uteis sim, mais uma analise clinica de um bom DBA ainda é muito mais válida do que scripts ou correções pré-formatadas.

Espero que tenham gostado, é um artigo pequeno apenas para criar uma discussão sobre um assunto muito pertinente no nosso cotidiano.

SUCESSO Á TODOS!!!...