Blog da Lilian Barroso

Dia desses tivemos que migrar um banco de dados de 9i para 10g, com o tamanho aproximado de 4 TB, sob um ambiente IBM AIX 5.1.

Apesar de um pouco conturbada, a migração para 10g foi realizada com sucesso; isto até que seria um tópico interessante para um post, mas hoje eu preferi abordar outro assunto: A criação de um standby para este banco de dados.

Este é um recurso do Oracle database conhecido como Oracle Data Guard; Neste caso, foi criado um banco standby físico.

Motivos para criar um banco standby não faltam. Proteção contra erros lógicos (comparado a um standby database lógico), failover rápido, possível switch over em casos de necessidade de manutenção no servidor primário, possíbilidade de abrir o banco standby em ready-only para a geração de relatórios, entre outras coisas.

Como pré-requisitos, o banco primário deve estar em archivelog - uma vez que as alterações serão replicadas através da aplicação dos relo logs arquivados; o banco primário também deverá usar arquivo de senhas.

Que tal conhecer como funcionou a criação deste standby?

INICIANDO A CRIAÇÃO

Inicialmente, para criar o banco de dados standby, deve ser instalado o software do Oracle. Utilizamos a interface gráfica do instalador, escolhendo a opção “Install database Software only”.

Para facilitar em caso de failover, foi criada a mesma estrutura de diretório dos arquivos do banco primário no novo servidor. Isto também ajudou na cópia dos datafiles (uma vez que optamos por copiar um a um via Begin backup).

Por que Begin backup?

Neste caso, uma série de fatores nos levou à opção de copiar os datafiles um a um, mas os principais foram o tamanho do banco e sua criticidade, o que não permitiu uma parada do ambiente para uma cópia a frio.

Copiando os datafiles

Antes de inciar a cópia, é interessante anotar o número do último archive gerado (Este será o primeiro archive a ser copiado no standby)

select max(sequence#)   from v$log_history;

Após anotar o n. do archive, foi iniciada a cópia dos mais de 600 datafiles do banco.

Mas, não pense que fiquei olhando a cópia de datafile por datafile… foi feito um script que colocava cada tablespace em Begin backup, copiava os datafiles com scp, e colocava novamente a tablespace em end backup. Veja um pedaço do script:

alter tablespace users   begin backup;

ho scp -r -C   \oracle\oradata\orcl\tblusers01.dbf 192.168.1.10:\oracle\oradata\orcl\

ho scp -r -C   \oracle\oradata\orcl\tblusers02.dbf 192.168.1.10:\oracle\oradata\orcl\

alter tablespace users   end backup;

Lembrando que, para não ficar tendo que inserir senha toda hora, é possível criar uma chave pública entre os dois servidores, como expliquei em um dos meus posts (ver post).

Para saber quais são os datafiles do banco de dados, consulte a view dba_data_files:

select file_name from   dba_data_files order by tablespace_name;

Durante a cópia, o alert.log deve ser acompanhado, verificando se as tablespaces estão ficando em Begin backup / end backup corretamente.

Para ver as alterações do alert em tempo real, utilize o comando tail -f. Veja um exemplo de comando:

tail -f alert_ORCL.log

Também dá para acompanhar as alterações das tablespaces através da seguinte consulta:

select   df.tablespace_name, df.file_id

from dba_data_files   df,  v$backup b

where df.file_id =   b.file#

and b.status =   ‘ACTIVE’;

Também copiei os tempfiles e os redos log files, os quais foram localizados através das consultas abaixo:

select file_name from   dba_temp_files;

select member from   v$log_member;

Standby Controlfile

Ao final da cópia dos arquivos, criei no banco primário um controlfile especial: o standby controlfile.

alter database create   standby controlfile as ‘/home/oracle/migracao10g/orclstd.ctl’

Este controlfile foi copiado para o servidor secundário, com o cuidado de criar duas cópias e renomeá-las.

Copiando os archives

Neste ponto, foi a hora de copiar todos os archives gerados para o destino. Estes archives são importantes para o recover dos datafiles copiados em Begin backup, e para abrir o banco em read only.

Parâmetros da instância

Para um banco reconhecer o outro, haver a replicação dos archives e ativar os processos de background necessários, é necessário adicionar alguns parâmetros.

No banco de produção, foram ativados o log_archive_dest_2, log_archive_dest_state_2, standby_file_management, fal_server e fal_client . Todos estes parâmetros podem ser ativados com ALTER SYSTEM .

Uma observação importante é o valor do parâmetro log_archive_dest_2: ele deve estar de acordo com o alias utilizado para o banco standby no tnsnames do servidor, como no exemplo abaixo:

Também devem ser ajustados tais parâmetros no standby. Porém, eu fiz diferente: Primeiro, criei um pfile a partir do spfile da produção, e editei este arquivo. Depois, copiei o mesmo para o servidor standby.

Para criar um pfile:

create pfile=’/home/oracle/migracao10g/initorcl.ora’ from spfile;

Veja um exemplo de pfile para um banco standby:

orcl.__db_cache_size=34158411776orcl.__java_pool_size=83886080

orcl.__large_pool_size=33554432

orcl.__shared_pool_size=3238002688

orcl.__streams_pool_size=50331648

aq_tm_processes=1

archive_lag_target=60

background_dump_dest=’/oracle/admin/orcl/10g/bdump’

compatible=’10.2.0.4.0′

control_file_record_keep_time=7

control_files=’/oracle/syst/u01/oradata/orcl/control01.ctl’,
              ‘/oracle/syst/u01/oradata/orcl/control02.ctl’,
              ‘/oracle/syst/u01/oradata/orcl/control03.ctl’

core_dump_dest=’/oracle/admin/orcl/10g/cdump’

cursor_sharing=’EXACT’

db_block_size=8192

db_cache_size=0

db_domain=”

db_file_multiblock_read_count=16

db_files=2048

db_name=’orcl’

db_writer_processes=5

dispatchers=’(PROTOCOL=TCP)   (SERVICE=orclXDB)’

dml_locks=3892

fal_client=’ORCLSTD’

fal_server=’ORCL’

fast_start_mttr_target=300

filesystemio_options=’asynch’

hash_area_size=1048576

instance_name=’orcl’

java_pool_size=0

job_queue_processes=18

large_pool_size=0

log_archive_dest_1=’LOCATION=/oracle/arch/u01/orcl/archive/’

log_archive_format=’orcl_%t_%s_%r.arc’

log_archive_max_processes=1

log_buffer=10048576

log_file_name_convert=’/oracle/redo/u01/oradata/orcl/’,
                      ‘/oracle/redo/u01/oradata/orcl/’,
                      ‘/oracle/redo/u01/oradata/orcl/’,
                      ‘/oracle/redo/u01/oradata/orcl/’,
open_cursors=2000

optimizer_dynamic_sampling=2

optimizer_features_enable=’10.2.0.4′

optimizer_index_caching=25

optimizer_index_cost_adj=10

pga_aggregate_target=7G

processes=1200

query_rewrite_enabled=’TRUE’

recovery_parallelism=16

recyclebin=’OFF’

remote_login_passwordfile=’EXCLUSIVE’

service_names=’ORCL’

session_cached_cursors=200

session_max_open_files=20

sessions=1200

sga_max_size=35G

sga_target=35G

shared_pool_reserved_size=124151398

shared_pool_size=0

skip_unusable_indexes=TRUE

sort_area_size=1048576

standby_archive_dest=’/oracle/arch/u01/orcl/archive/’

standby_file_management=’MANUAL’

star_transformation_enabled=’FALSE’

streams_pool_size=50331648

transactions=973

undo_management=’AUTO’

undo_retention=5400

undo_tablespace=’UNDOTBS2′

user_dump_dest=’/oracle/admin/orcl/10g/udump’

Arquivo de senhas

Outro item importantíssimo é a cópia (ou criação) do arquivo de senhas. Geralmente, ele está no diretório $ORACLE_HOME/dbs, e tem o nome orapw<nome_instancia> (por exemplo, orapworcl). Lembrando que a senha do sys no banco standby deve ser a mesma do banco primário.

Para criar um arquivo de senhas:

orapwd file=<caminho/arquivo>  password=<senha do sys> entries=10

exemplo:

orapwd file=/oracle/10g/dbs/orapworcl  password=change_on_install entries=10

Importante: o parâmetro remote_login_passwordfile deve ter valor exclusive ou shared.

Configurando as variáveis de ambiente

Para ajustar as variáveis de ambiente e outras configurações do usuário Oracle, ajustei o arquivo .profile (geralmente fica dentro do diretório /home do usuário).

Exemplo de arquivo .profile

EDITOR=viORACLE_BASE=/oracle

ORACLE_HOME=$ORACLE_BASE/10g

ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data

ORACLE_SID=orcl

LIBPATH=$ORACLE_HOME/lib:/usr/lib

PATH=$PATH:$ORACLE_HOME/bin:/usr/bin:/etc:/usr/bin/X11:/usr/local/bin

export PATH ORACLE_BASE ORACLE_HOME PATH ORA_NLS33 ORACLE_SID LIBPATH EDITOR

Também foi ajustado o arquivo /etc/oratab, como no exemplo abaixo:

Subindo o banco de dados

Com todos estes procedimentos, foi possível subir a instância, utilizando o pfile criado:

sqlplus “/as sysdba”

startup nomount pfile=/home/oracle/migracao10g/initorcl.ora

É importante acompanhar, em sessão paralela, o alert.log do banco: caso haja algum erro, através dele é possível ver detalhes do problema, e eventuais arquivos de trace gerados.

Com a instância no ar, foi criado um spfile, e ela restartada em mount.

Veja exemplo de comandos:

create spfile from   pfile=’/home/oracle/migracao10g/initorcl.ora’;

shutdown immediate

startup mount

Redo Aply

Para iniciar a recuperação do banco, através da aplicação dos archives no banco de dados, utilizamos o comando abaixo:

RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Este comando inicia o processo de background MRP (Managed Standby Recovery) em background, e é possível verificar no alert.log do banco o processo.

É interessante notar não ser preciso subir o standby com o comando “mount standby”: O Oracle 10g verifica o tipo do controlfile ao montar o banco; se o controlfile for de standby, automaticamente o banco é montado como standby.

Todos os archives copiados via SCP foram recuperados no banco. Após esta recuperação, ele começará automaticamente a recuperar os archives copiados via RFS do servidor primário; quando não há mais archives novos, a seguinte mensagem é exibida:

Ou seja, o banco está esperando o próximo archive, vindo da produção, para aplicar no standby.

Neste momento, é possível abrir o banco para consultas (read only)

Comandos:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

ALTER DATABASE OPEN   READ ONLY;

Veja como fica o alert:

Verificando se os bancos estão sincronizados

Para verificar se os bancos primário e secundário estão sincronizados, verifique se o último archive gerado na produção foi o último replicado no secundário, através do alert.log de ambos.

Outra forma é consultando a view v$log_history nos dois bancos:

select max(sequence#) from v$log_history;

…

Bem, depois de tanto tempo sem postar nada, espero que seja útil!

Até mais,

Lílian

Para saber mais:

Na internet:

Oracle Database 11g Editions

Introduction to Oracle Data Guard

Livro:

Oracle database 10g High Availability with RAC, flashback & Data Guard

Ei pessoal!

Rápido e rasteiro!

Conhecem a tabela SYS.LINK$? É uma tabela interna do banco de dados que contém todas as informações sobre db_links do banco de dados.

Vejam a descrição dela em um banco Oracle 9i (velho, mas presente em muitas empresas):

SQL> desc SYS.LINK$
Nome
————————-
OWNER#
NAME
CTIME
HOST
USERID
PASSWORD
FLAG
AUTHUSR
AUTHPWD

Observem o campo PASSWORD: ele contém a senha do usuário utilizado no dblink … sem criptografia.

(corrigido na versão 10G).

Só para comparação: Colunas da view dba_database_links:

SQL> desc dba_db_links
Nome
————————–
OWNER
DB_LINK
USERNAME
HOST
CREATED

t+,

Lílian

Oi a todos? Como foram de carnaval???

Como muitos já sabem, trabalho de dba não tem dia nem horário… é possível que você tenha que trabalhar depois do expediente, aos domingos e feriados, etc.
E, este foi o meu caso: estava de plantão e em plena terça de carnaval, e com isso, fui trabalhar (nem deu pra aproveitar a festa da Roseira da Freguesia do Ó).
O bom é que quase não houve chamados para eu atender; desta forma, pude adiantar algumas das minhas (muitas) pendências (finalmente alguns post-its puderam ir para a Lixeira).
Foi o que eu fiz: Dentre muitas resolvidas, cito as três mais simples (porém não menos importantes):

1 - Finalmente desfiz o dual-boot do meu computador: A partir de hoje, apenas Linux!

2 - Fiz um script para fazer backup dos agendamentos e scripts das crontabs de tais servidores.

3 - Terminei outro script para  centralizar o log de backup das 20 instâncias aix sob oracle 9i que administramos;

1 - Linux no notebook
Depois de mais de 1 ano ter postado no blog sobre utilizar Linux, apenas agora tive coragem de instalar apenas ele no computador. Bem, instalei o Ubuntu 9.04, mas isto será assunto para outro post

2 - Script para backup da crontab
É uma coisa muito simples, mas essencial! Às vezes a gente passa o dia todo implementando um script para automatizar alguma tarefa, agenda seu funcionamento na crontab mas… esquecemo-nos de fazer cópias de segurança …
O pior - e mais fácil de acontecer - é perder todos os agendamentos da crontab! Vocês já repararam como o “E” fica próximo do “R” no teclado??? Infelismente o AIX não pergunta “Do you really want remove all schedules?” após pressionar ctrl+R.
Como todos os scripts que utilizo geralmente ficam armazenados no diretório /usr/local/scripts , ficou mais fácil:

 cd  /usr/local/scripts                                                                    
 DIA=`/usr/bin/date +%d +- +%m +- +%y`                                                 
 crontab -l > “$DIA”_crontab.bkp                                                       
 tar -cf “$DIA”_backup_scripts.tar *.ksh “$WDAY”_crontab.bkp                           
 gzip “$DIA”_backup_scripts.tar                                                        
 rm -rf “$DIA”_crontab.bkp

Resumindo: O script trabalha dentro do diretório /usr/local/scripts, cria um arquivo compactado com o conteúdo da crontab, todos os arquivos com extensão *.ksh e nomea-o com a data de criação.

Este script pode ficar ainda melhor se enviado para outro servidor, fita, etc…

3- Centralizando os logs de backup
Este creio que foi o mais simples e o que mais me ajudou.
Diariamente, temos que verificar os logs de backup de umas 25 instâncias que rodam Oracle 9i. Só de entrar em servidor por servidor e olhar o log gastávamos em torno de 30 minutos por dia, além de ser um trabalho extremamento chato.
Solução: Concentrei todos os logs em apenas 1 documento, em apenas 1 servidor!
Para fazer isso, utilizei o conceito de autenticação chave pública/privada do serviço SSH: gerei uma chave sem senha no servidor de destino dos logs, para efetuar remotamente o comando tail em todos os servidores.

Basicamente, são 2 passos:
A - Criar chave pública e copiá-la nos servidores de origem
 – Comandos: –

 ssh-keygen -t rsa -b 1024

   # onde -t significa tipo
   # onde -b significa tamanho em bytes da criptografia
 Na mensagem “Enter file in which to save the key (/home/oracle/.ssh/id_rsa):”  Pressionei Enter
 Na mensagem “Enter passphrase (empty for no passphrase):”  Enter de novo
  Na mensagem “Enter same passphrase again:” Pressione Enter outra vez
 A mensagem “Your identification has been saved in  . ” demonstra o arquivo onde está a chave privada do servidor.
 Geralmente, o arquivo fica dentro do home do usuário, dentro do diretório .ssh/ , com a extensão .pub
 
– Veja os comandos que utilizei –
  cd  –> para entrar no diretório home do usuário corrente
  cat .ssh/id_rsa.pub –> para obter a chave gerada.
 
 O conteúdo do arquivo *.pub  foi copiado em todos os outros servidores, onde os logs de backup são gerados. No caso do AIX, este arquivo tem o nome id_rsa.pub.
 Em tais servidores, copiei a linha de código gerada no arquivo .ssh/authorized_keys, que fica no diretório home do usuário do SO.
   
B - Criar o script para reunir os logs
 Depois de fazer o trabalho pesado, que é entrar servidor por servidor e copiar a chave pública, no servidor de destino eu criei um script para “puxar” as últimas 20 linhas de cada log de backup:
 Basicamente, os comandos inseridos dentro do script tem a seguinte sintaxe:
  ssh <usuario>@<servidor> “tail -20 /<caminho>/<arquivo_de_log>”
 Por exemplo
 ssh oracle@serverora41″tail -20 /usr/local/logs/rman_full_sdemp.log” >> /usr/local/logs/logs_centralizados.log
 
 Com isso, os logs de backup ficaram em apenas 1 arquivo (no exemplo acima, dentro de “logs_centralizados.log”).
 
Para melhorar, agendei a execução deste script 1 vez ao dia, e o resultado está sendo enviado por e-mail. Desta fora, 30 minutos tranformam-se em 3: o tempo de abrir o e-mail!
Bem, com isso, posso dizer que meus scripts de carnaval vão me ajudar o ano todo… Epa, peraí: Será que o ano realmente começa no carnaval?

Se for assim, feliz ano novo! Desejo a todos muitos scripts de sucesso!

Para saber mais sobre ssh:

 http://www.vivaolinux.com.br/artigo/SSH-completo-%28passo-a-passo%29/
 http://focalinux.cipsga.org.br/guia/avancado/ch-s-ssh.htm

PS: Um grande abraço para meus colegas de trabalho Alan e Hernani, grandes incentivadores na instalação do Linux no note, e elaboração dos scritps.

(baseado em fatos reais)

Um dia, olhando um parâmetro de um certo banco de dados, um DBA descobriu que o parâmetro estava em 1, enquanto que o normal seria 10. Ao verificar o motivo, descobriu que o script responsável por modificar este parâmetro não estava funcionando há tempos, devido a uma mudança de diretórios …

Com isso, nos questionamos: quem foi que alterou o script? E melhor, por que?

Bem, neste momento o DBA nos contou um historinha: Era uma vez um menininho, que indo para a casa da sua avó, passou por debaixo de uma árvora muito alta. E, ao observar um dos galhos, notou uma tartaruga sobre ele! “Que estranho!”, pensou , ” Tartarugas não sobem em árvores? O que ela está fazendo lá? Por que? ”

Uma coisa é fato: Alguém colocou lá. Assim como tal script. Assim como o tal alter system set alguma_coisa .

O fato é que há muitos ambientes de TI iguais à narrativa; alias, alguns ambientes estão tão cheios de tartarugas sobre galhos, que alguns já enxergam isso como natural.

Tão natural que um amigo meu, analista unix, soltou logo depois da narrativa: “Não é uma árvore cheia de tartarugas! É um pé de Tartaruga.”

Moral da história: Caro colega, please, documente!  /* (canja de galinha) */ não faz mal a ninguém. Comentários não consomem horas de trabalho, mas podem poupá-las!

Vamos evitar que a bagunça generalizada torne-se normal, assim facilitando nossa atividade diária.

(Lílian)

Oi Caros

Admito: desde que publiquei um post sobre minha vontade de prestar prova para certificação, não tive mais coragem de escrever - enquanto não marquei e, após marcar, não tive coragem de fazer mais posts enquanto não tivesse feito a prova.

Mas, é fogo! Até que ponto uma prova realmente prova que você é um bom profissional?

Eu realmente detesto provas. Não querendo desmerecer os certificados, mas provas em geral - isoladamente, não provam nada - e isso diz respeito a qualquer tipo de prova.  Por exemplo, quem não conhece pessoas que dirigem super bem e reprovam no exame do Detran? Ou os malfadados vestibulares, que tentam resumir em 4 horas a vida inteira de um estudante: por melhor que ele tenha sido por anos, um pequeno distúrbio intestinal é capaz de levá-lo à ruína.

Alias, foram os vestibulares os vilões do meu nervosismo pré-provas.

Sim. Além de achar que provas não provam nada, também fico extremamente nervosa antes delas, e isso começou na época pré-faculdade. Eu tentei 3 vezes passar em vestibulares públicos, sendo que nas duas primeiras tentativas fiquei na lista de espera (isso é pior que nem ver seu nome na lista… um sentimento indescritível de ser o primeiro dos últimos).

E, com este nervosismo, cancelei duas vezes a bendita IZ0-047.

É terrível! A cobranças das pessoas, o valor da prova jogado no lixo em caso de reprovação, o aumento de salário que pode não vir. Ah, sem falar daqueles fulanos que te julgam apenas pela falta do certificado…

Mas, não devemos encarar as provas como nossas vilãs, e sim como aliadas.  Mesmo sabendo que isoladamente elas não são nada, somadas a um contexto elas são fundamentais. O profissional de informática pode ser um excelente técnico, ter um grande networking e relacionar-se extremamente bem com os clientes; mas a falta de certificações sempre será uma grande lacuna.

Em uma certa ocasião, já me disseram: ” um diploma é como um cinto de segurança: na hora ‘H’ ele faz a diferença”; assim são as certificações: em uma seleção, o tal “papel” faz a diferença perante os concorrentes.

E, no final das contas, assim como tirar carta ou passar no vestibular, a sensação de passar no teste é sublime! Hoje estou me sentindo tão bem quanto eu peguei a “carta”, ou quando vi meu nome na lista da fuvest: hoje, com muita felicidade, posso falar: finalmente eu passei em uma prova de certificação!

Finalmente? Não. Apenas o começo de muitas.

Um abraço a todos, especialmente àqueles que estão ensaiando pra certificação! Go ahead!

Caros… após muito tempo , cá estou de volta!

Depois de muito tempo enrolando, não sei se por medo ou comodismo… ou pelos dois, finalmente marquei a prova para certificação.

Depois de muito pensar, optei pela iz0-047: SQL Expert. Das provas pré-req para OCA, é a mais abrangente (e mais cara, US$ 125), mas dá pra passar com 66% e tb fornece certificação.

Bem, se for para eu me matar de estudar, é melhor que seja para tirar uma certificação, né! Neste caso, se caso eu passar, serei cetificada “SQL Certified Expert” .

Para os curiosos, esta prova é presencial (ao contrário da iz0-007), cai ítens do 11G, é apenas em inglês, tem 70 questões e dura 120 minutos (2 horas).

Não é necessário fazer curso oficial para fazê-la, por isso você pode estudar em casa mesmo antes de prestar; no meu caso, eu comprei o livro “Oracle Database 11g SQL”, da Oracle Press.

Algumas pessoas contam com a ajuda de simulados para estudar… bem, como são um pouco caros, ainda estou em dúvida se devo comprar um ou não. Caso você queira maiores infomações, entre no site do Test King (empresa especializada em simulados).

No próximo post mostrarei como é feito para agendarmos a prova, via internet, no site da Person Vue.

Um abraço,
Lílian

Caros colegas do GPO Blogs!

Tudo bem?

Creio que muitos leitores estejam passando pelo dilema de tirar ou não certificação Oracle. No meu caso, eu adiei um pouco, visto que aqui na empresa não trabalhamos apenas com Oracle, mas com outros SGBDs como MySQL, SqlServer e DB2; como a minha formação é essencialmente Oracle, sob plataforma Windows, passei estes últimos seis meses balanceando os estudos entre estes SGBDs  e unix/linux.

Pois bem. Agora, mais do que nunca chegou a hora de “tomar vergonha na cara” e fazer as benditas provas. “Vergonha na cara” porque:

- É um passo importante na carreira de um profissional de TI (principalmente para os DBA’s);

- Elas aumentam a empregabilidade e o respeito ao DBA;

- Minha empresa paga as certificações;

- A maior parte dos meus colegas têm certificações (o Portilho tira uma por mês!) ;

O que mais tem me atrapalhado a enfrentar a fera é em primeiro lugar a insegurança… sabe aquele friozinho na barriga antes de prestar vestibular? Então, estou sentido algo bem parecido… por mais que eu estude, parece que nunca é o suficiente!  Mas, é comparando ao vestibular que eu vou fazer a prova. Sei que não é impossível, pois conheço muitas pessoas que passaram (tenho um colega que não tem muita experiência e conseguiu tornar-se OCP).

Como tornar-se certificado

Conforme o ótimo post do nosso colega Rodrigo Almeida, a primeira certificação para o DBA Oracle é a OCA, que tem como pre-requisito uma das quatro provas abaixo:

• 1Z0-001 - Introduction to Oracle: SQL and PL-SQL
• 1Z0-007 - Introduction to Oracle: SQL
• 1Z0-047 - Oracle Database: SQL Expert
• 1Z0-051 - Oracle Database 11g: Fundamentals I

Analisando o grau de dificuldade de cada uma, e contrastando com os meus conhecimentos, decidi prestar a 1Z0-007.  Ela aborda os principais conceitos de SQL, e dá para estudar a partir da documentação oficial (disponível gratuitamente no site da Oracle).

1Z0-007

Para ajudar meus estudos, eu peguei no site da Oracle os tópicos que caem na prova, coloquei em uma planilha e mapeei meus pontos fortes e meus pontos fracos. Os pontos fracos, estou dando uma estudada mais puxada, e os pontos fortes, apenas revisando.

Se você, como eu, decidir estudar sozinho, os tópicos da prova são:
ARQUITETURA
–> Arquitetura Oracle e seus componentes
–> Arquitetura da instância Oracle

INSTALANDO O SOFTAWARE DO ORACLE DATABASE
–> Ferramentas administrativas comuns acessíveis ao DBA
–> OFA
–> Oracle Universal Installer
–> Variáveis de ambiente comumente usadas
–> Log de instalação

CRIANDO UM BANCO DE DADOS ORACLE
–> DBCA: criando e apagando bancos de dados, e gerenciando templates

GERENCIANDO A INSTÂNCIA ORACLE
–> Enterprise Manager
–> SQL*Plus and iSQL*Plus para acesso à instância
–> Parâmetros de inicialização
–> Estágios de startup
–> Opções de shutdown
–> Alert log
–> Dynamic performance views

GERENCIANDO ESTRUTURAS DE ARMAZENAMENTO DO BANCO DE DADOS
–> Como a tabela é armazenada (blocos de dados)
–> Tablespaces: objetivos, manipulação e gerenciamento.
–> ASM: features e benefícios

ADMINISTRANDO USUÁRIOS (SEGURANÇA)
–> Criando e gerenciando contas de usuários
–> Roles
–> Privilégios
–> Profiles
GERENCIANDO OBJETOS DE SCHEMAS
–> Tabelas (criando e gerenciando)
–> Constraints
–> Conceitos e usos de índices B-Tree and Bitmap
–> Criando Views e sequences
–> Dicionário de Dados

GERENCIANDO DADOS E CONCORRÊNCIA
–> Manipulate  dados com SQL
–> Objetos PL/SQL
–> Triggers e eventos de triggers

–> Níveis de  locking
–> Possíveis causas de conflito de lock
–> Monitorar e resolver conflitos de lock

GERENCIANDO DADOS DE UNDO
–> Monitorando e gerenciando Undo
–> Undo retention
–> Relacionamento entre Undo e transações
–> Tamanho da tablespace de undo

IMPLEMENTANDO SEGURANÇA NO ORACLE DATABASE
–> Princípio do menor privilégio
–> Auditoria

CONFIGURANDO O AMBIENTE DE REDE ORACLE
–> Gerenciando e criando listeners adicionais e Alias do Oracle Net service com Database Control
–> Conexão compartilhada e dedicada

MANUTENÇÃO PROATIVA
–> Coletando Estatísticas
–> Gerenciando o  Automatic Workload Repository
–> ADDM
–> Alertas
–> Pontos de performance
GERENCIAMENTO DE PERFORMANCE
–> Uso do Enterprise Manager para visualizar performance
–> Ajuste de  SQL através do SQL tuning advisor e do access advisor
–> Automatic shared memory management
–> Memory advisor : size memory buffer

CONCEITOS DE BACKUP E RECOVERY
–> Tipos de falhas que podem ocorrer do banco de dados Oracle
–> Importância dos checkpoints, redo log files, e archived log files
–> Ajustando instance recovery
–> Configurando um database para recuperabilidade
–> Configurando modo ARCHIVELOG

BACKUP DE BANCO DE DADOS
–> Backups consistentes
–> Backups off-line
–> Backups incrementais
–> Backups Automáticos
–> Backup  control file to trace
–> Flash recovery area

RECUPERAÇÃO DE BANCO DE DADOS
–> Recuperar :  Control file, Redo log, data files

FLASHBACK
–> Flashback database
–> Recuperando dados point in time
–> Recuperando tabelas dropadas
–> Usando Consultas Flashback
–> Visualisando histórico de transações

MOVIMENTANDO DADOS
–> Arquitetura do Data Pump
–> Data Pump export e import
–> Load dados com SQL Loader
–> Usando tabelas externas para mover datas

Material de Estudo

Para quem quizer me acompanhar nesta empreitada:

Livro: Price, Jason: Oracle Database 11g SQL - editora Bookman (Oracle Press) - Em português

Documentação Oficial: Oracle9i SQL Reference Release 2 (A96540-02)

Site: Oracle Certification Program - Introduction to Oracle9i SQL®

Boa sorte a todos!!!

Lílian

Oi pessoal!!

Admito! É vergonhoso o tempo que estou sem postar no blog….  E, o mais vergonhoso que tenho pelo menos uns 10 rascunhos na pen drive e nunca termino de editar.

Bem, para matar a saudade, as últimas novidades:

- O “Café com o GPO” ontem foi o máximo! O que deveria ser um bate-papo com o Ricardo Portilho e com o Rodrigo Almeida virou um saudável debate entre os participantes… os “penetras” revolucionaram este programa, entrando com tudo na conversa - como quem entra sem ser chamado e fica porque ficou interessante?! (não posso deixar de citar a pérola “Campo do tipo blog que soltaram… espero que o Willian não edite, kkkk)

- Twitter: Agora tb faço parte!

- Restore: Fiz um restore de um banco de dados que ficou muito interessante para postar… o  texto está no forno.

- Senac: Estão abertas inscrições para o programa Senac de Gratuidade! Estão sendo oferecidas bolsas de estudo gratuitas para vários cursos, inclusive para formação Oracle DBA (unidades Campinas e Sorocaba).  Se você tem renda familiar per capita de 1,5 salário mínimo federal tem direito a concorrer. Vale a pena dar uma conferida.

- The Edge: Rádio Canadense que toca rock e tem apresentadores muito divertidos… dá para escutar boa música, rir um pouco e ainda por cima treinar o Inglês (nunca achei que adoraria escutar uma propaganda do Subway, rsrs). Dá para escutar pela Internet.

Um abraço,

Lílian !

Tuning vem do verbo em inglês to tune, que pode ser traduzido como “ajustar”.

Calma, este post não será sobre tuning automotivo … se bem que eu gostaria muito de comentar sobre as rodas e o aerofólio que estou querendo comprar para o meu pálio, rsrs. O assunto agora é  Tuning de banco de dados.

Conceito

Tuning de banco de dados refere-se a ações de ajuste no servidor Oracle a fim de prover performance.
As ações de ajuste no banco de dados geralmente são feitas com o sistema já em pé, funcionando a todo o vapor… e com os usuários reclamando que tá tudo lento! O ideal é que o tuning seja feito de forma proativa e diária.

Metodos de tuning

Como dito anteriormente, o tuning pode ser feito por duas razões: Preventivamente ou reativamente. É obvio que tunar o sistema durante sua implementação é o ideal, dentro daquele novíssimo ditado “melhor prevenir do que remediar”. Porém, como todos já sabemos, a maior parte das açoes de tuning é reativa: o usuário final reclama de lentidão, e lá vai o DBA correr atrás do problema, muitas vezes gerando retrabalho.

Porém, não adianta muito analisar um problema isoladamente no banco de dados, e é isso que quero demonstar neste post: Devemos olhar o servidor de banco de dados como um todo, envolvendo o hardware, o sistema operacional, a aplicação e o próprio servidor oracle.

Outra coisa importante: não pense que tuning é uma ação única e definitiva: ele deve ser constante, fazendo parte da rotina de todo administrador de banco de dados.
A Oracle recomenda que seja seguida uma ordem nos passos de tuning, sendo que os passos com maior impacto devem ser realizados primeiro.
Abaixo, os passos (por prioridade de ajuste):

1º - A regra de negócio
2º - A modelagem dos dados
3º - A modelagem da aplicação
4º - A estrutura lógica do banco de dados
5º - As operações do banco de dados
6º - O caminho de acesso
7º - Memória
8º - I/O e estrutura física
9º - Contenção de recursos
10º - Plataforma Base

- 1 - Regra de Negócio

O planejamento das necessidades de performance correspondem diretamente à necessidade do negócio.

Com as regras de negócio, conseguimos levantar qual a espectativa do numero de usuários concorrentes, o tempo de resposta da transação, o número de dados gravados online que o sistema deverá suportar.
- 2 - Modelagem dos Dados

Nesta fase, de acordo com as regras de negócio, é importante determinar que tipo de dados deverão ser armazenados. Deverão ser definidos quais os relacionamentos e atributos são importantes para o sistema, consequentemente, as chaves primárias e estrangeiras.

É aqui que são definidos qual o nível de normalização a ser utilizado. Geralmente, normalizar até a 3º forma normal é recomendado, porém, de acordo (de novo) com as regras de negócio, algumas estruturas podem ser desnormalizadas (visando performance)

É neste ponto que você deverá considerar :
a) O particionamento de dados;
b) o uso de índices globais ou locais.

- 3 - Modelagem da Aplicação

Neste ponto, é necessário “traduzir” os objetivos do negócio em um sistema efetivo. Alguns processos podem tornar-se desde funcionalidades, ou até sistemas completos. É aqui que devem ser consideradas a configuração dos processos individualmente.

- 4 - Estrutura Lógica

Depois da modelagem do sistema e da aplicação, é a hora de “conceber” o banco de dados. No passo 2, foram definidas as chaves primárias e estrangeiras, e agora é hora de “refinar” estes índices, além de acrescentar índices adicionais para suprimir todas as necessidades da aplicação.

- 5 - Operações

Agora é a hora de tunar nossas “benditas” queries. No mundo ideal, os desenvolvedores de aplicação (e arquitetos de sistema) deveriam conhecer o funcionamento do Oracle na recuperação dos dados, a fim de escrever códigos sql <<<consistentes>>>. É nesta parte onde estão concentrados os maiores problemas de performance - e onde o DBA mais sofre. Preventivamente, o dba deve acompanhar este processo, orientando os programadores a utilizar corretamente os recursos do banco de dados, como os índices, funções, hints.

Na minha humilde opinião, todo o dba deve explicar -neste ponto- o que é o Oracle Optmizer ( nos próximos posts irei falar sobre ele, nosso maior amigo).

- 6 - Caminho de Acesso

Neste passo, deve ser assegurado o acesso eficiente aos dados, considerando o uso de clusters, hash clusters, índices B-Tree e indices de bitmap.

- 7 - Memória

Este ponto diz respeito à correta alocação de memória para as estruturas do servidor Oracle, como o dicionario de dados, library cache, buffer cache, entre outras.
É aqui onde muito DBA comete o terrível erro de alocar mais memória para a SGA do que o sistema tem disponível, afetando o desempenho do Sistema Operacional, além de causar terríveis swappings…

- 8 -  I/O e estrutura física
É um problema que afeta o desempenho do servidor como um todo. O processo de tuning de I/O e estruturas físicas envolve, entre outros coisas, a distribuição dos dados de acordo com os dispositivos existentes, evitando contenção de disco.

A sugestão da IBM para distribuição de discos é a separação dos dados, conforme abaixo:
* Tablespaces de dados
* Tablespaces temporárias
* Segmentos de redo log
* Dados do aplicativo
* Índices de aplicativos

- 9 - Contenção de Recursos

Processamento concorrente causado pelo acesso de multíplos usuários pode causar contenção de recursos do Oracle.
Deve-se ter atenção aos seguintes tipos de contenção:
* Block contention
* Shared pool contention
* Lock contention
* Pinging (in a parallel server environment)
* Latch contention

- 10  - Plataforma Base

De acordo com a plataforma escolhida, há ítens que devem ser ajustados. Por exemplo, em ambientes Unix devemos nos atentar a:
* Tamanho do UNIX buffer cache
* Gerenciamento dos Logical volume
* Memória tamanho para cada processo.

Bem, este post é uma introdução à outros que pretendo colocar no site a respeito de tuning, especialmente sobre tuning de aplicação  (que é onde tenho mais experiência).  Lembrando que os passos acima são recomendações da Oracle e dizem respeito ao mundo ideal (se você está terminando a graduação, é isto que seu professor vai querer encontrar no seu TCC, rsrs).

Então,

Até mais!

Galera, uma historinha baseada em fatos reais, com final feliz forçado, rsrs…

Há mais ou menos um mês atras, um dos nossos clientes entrou em contato reclamando que um dos usuários não estava conseguindo usar a aplicação.

O erro retornado era: “ORA-01591 lock held by in doubt distributed transaction”.

Engraçado que ao tentar entrar no sqlplus ou no sqldeveloper (a partir da minha máquina), o mesmo erro aparecia:

Na segunda tentativa, consegui conectar. Porém, ao tentar rodar um script de verificação das sessões, o tal erro de novo:

Bem, tentei entrar localmente, através do sql plus do servidor como sysdba (via Putty)… e não é que o mesmo erro aparece!

Porém, assim como aconteceu com o SqlDeveloper, consegui conectar na segunda tentativa. Como meus scripts não estavam funcionando, tentei dar um select * na v$session… e um erro de arrepiar:

O desespero bateu na porta!

Nesta hora, vi que era o momento de ”conversar com o google”. Após pesquisar alguns resultados, testei o seguinte comando:

select LOCAL_TRAN_ID
from sys.pending_trans$
Order by reco_time;

Mas… não entendi muito do resultado.  Dei um select * nesta tal sys.pending_trans$ , e verifiquei que tinha uma sessão com o status “prepared”

Tentei matar a sessão do usuário “infiliz”,  mas a sessão ficou killed e os erros continuaram.

E se tentarmos matar o processo do usuário pelo unix? Também não deu certo.

Blz… Hora de conversar com o Metalink

Quando a gente estava pensando em restartar o banco, inclusive avisando os poucos usuários que ainda estavam conectados, surge a OTN , e a luz no fim do túnel:

rollback force !!!

Após este comando,  ”só sucesso”! Veja como ficou o status da sessão:

Explicação: O Oracle não conseguiu concluir o recover da transação deste usuário, ficando com esta pendência.  Pelo que eu entendi, houve um corrompimento do dicionário de dados, por isso eu não conseguia estabelecer novas conexões ou fazer consultas simples como um describe.;

Para resolver, era necessário forçar o rollback, uma vez que o Oracle sozinho não estava conseguindo fazer isso. Para fazê-lo:

-  primeiro é necessário verificar o n. da transação a ser feito rollback
select * From sys.pending_trans$ Order by reco_time;
-  ou
select LOCAL_TRAN_ID from sys.pending_trans$ Order by reco_time;
-  depois, comando para forçar o rollback
rollback force ‘trans_id_from_result_above’;
- exemplo:

Interessante, não!? O legal foi descobrir que tinha uma dica no fórum do OTN que não tinha no Metalink! Daí a importância dos fóruns.

E assim terminou a nossa história, forçando nosso banco de dados a ter um lindo final feliz!

Glossário

- OTN - Oracle Technology Network: Site da Oracle voltado para prover serviços e informações à profissionais de TI que trabalham diretamente com a tecnologia Oracle, como DBA’s, desenvolvedores e arquitetos de sistema. Lá é possível encontrar tutoriais, downloads de programas (incluindo o Oracle Database), blogs e fóruns. Todo o DBA deve ter cadastro seu cadastro neste site.

- Metalink - Site oficial de suporte da Oracle, voltado para quem tem lisença de uso. É neste site onde são diponibilisados os downloads de patches, por exemplo.
Post no Fórum OTN:  forums.oracle.com/forums/thread.jspa?messageID=2056307

download do Oracle:  www.oracle.com/technology/software/products/database/index.html