Blog Flávio Soares
Oracle, Database, Data Guard, RAC, Performance, Exadata, ASM, Goldengate, Troubleshooting
April 19, 2013
Estava por esses dias aventurando novamente no photoshop, agora com menino propaganda da Oracle:
March 27, 2013
Lançado na versão Oracle 10g Release 1, o ASM passou por muitas mudanças até chegar onde chegou.
Os números abaixo além de impressionar, mostra um pouco até onde o ASM pode ir:
- Você pode ter até 63 disk group.
- Cada disk group pode ter até 10,000 ASM disks
- Cada disk group pode suportar um armazenamento de até 2TB.
- Cada diskgroup pode gerenciar até 1.000.000 (um milhão) de arquivos.
- Com a externa redundância: O tamanho máximo suportado por um datafile no Oracle ASM é de 140PB.
- Com a normal redundância: O tamanho máximo suportado por um datafile no Oracle ASM é de 42PB.
- Com a high redundância: O tamanho máximo suportado por um datafile no Oracle ASM é de 15PB.
Leram bem né?! Um datafile de 140 PB ….
February 15, 2013
…
Na parte 2 vimos como configurar e instalar o software do Oracle Database 11g.
Como é necessário duas máquinas virtuais para o nosso teste com Oracle Data Guard 11g, iremos então clonar literalmente a máquina DB Primary para a máquina a nova máquina virtual chamada DB Dataguard. Essa ação é muito fácil de ser feita com o VirtualBox, apenas com alguns cliques temos nossa máquina clonada.
Após a clonagem, teremos os seguintes ambientes para os testes de Dataguard:
Clonando a VM
Para clonar a VM DB Primary, siga os passos abaixos:
Clique na opção Clone … para abrir o assistente de configuração da nova máquina virtual.
Defina o nome como DB Dataguard.
Escolha a opção Full clone para iniciar a clonagem da VM.
Nesse ponto temos duas máquinas virtuais, uma chamada DB Primary que é nosso banco de dados produção e a VM DB Dataguard que é o Oracle Dataguard do banco de dados da máquina DB Primary.
Vamos iniciar a máquina DB Dataguard para iniciarmos as configurações nessa máquina.
Com a máquina ligada, clique em Administration depois Network.
Clique no botão EDIT para a interface eth0.
Defina o IP 20.0.0.20 para o endereço ip da interface.
Confirme a operação.
Agora na aba DNS mude o hostname para standdg.oracle.com
Agora precismos ativar a interface, para isso clique no botão Activate.
Agora, precisamos alterar o arquivo host da máquina, para isso, vamos conectar na máquina de Dataguard e mudar o arquivo de configuração /etc/hosts
FlavioSoares:VirtualBox VMs flaviosoares$ ssh root@20.0.0.20 The authenticity of host '20.0.0.20 (20.0.0.20)' can't be established. RSA key fingerprint is 66:86:82:d1:f4:72:1a:a0:55:c3:b2:65:f8:64:1f:17. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '20.0.0.20' (RSA) to the list of known hosts. root@20.0.0.20's password: Last login: Thu Jan 31 23:37:17 2013 [root@standdg ~]#
[root@standdg ~]# vi /etc/hosts
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 20.0.0.10 bancodg.oracle.com bancodg 20.0.0.20 standdg.oracle.com standdg [root@standdg ~]# [root@standdg ~]# hostname standdg.oracle.com [root@standdg ~]# hostname -i 20.0.0.20
Por último, precisamos mudar a variável de ambiente ORACLE_SID, para o banco que será o nosso Dataguard que no nosso caso chama-se stdby para o banco de Dataguard:
[oracle@standdg ~]$ cat ~/.bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
export ORACLE_SID=stdby
export PATH=$ORACLE_HOME/bin:$PATH
Teste de conectividade entre as VMs
Para iniciar os testes de conectividade das máquinas, inicie a VM DB Primary.
Com a máquina DB Primary ligada, conecte e realizar os testes abaixos.
FlavioSoares:VirtualBox VMs flaviosoares$ ssh root@20.0.0.10 root@20.0.0.10's password: Last login: Thu Jan 31 23:59:23 2013 from 20.0.0.1 [root@bancodg ~]# cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 20.0.0.10 bancodg.oracle.com bancodg 20.0.0.20 standdg.oracle.com standdg
[root@bancodg ~]# hostname
bancodg.oracle.com [root@bancodg ~]# ping standdg PING standdg.oracle.com (20.0.0.20) 56(84) bytes of data. 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=1 ttl=64 time=1.30 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=2 ttl=64 time=0.237 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=3 ttl=64 time=0.404 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=4 ttl=64 time=0.358 ms --- standdg.oracle.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 0.237/0.577/1.309/0.427 ms [root@bancodg ~]# ping standdg.oracle.com PING standdg.oracle.com (20.0.0.20) 56(84) bytes of data. 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=1 ttl=64 time=0.247 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=2 ttl=64 time=0.340 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=3 ttl=64 time=1.00 ms --- standdg.oracle.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.247/0.529/1.001/0.336 ms
Agora faça o teste inverso, da máquina virtual DB Dataguard faça o seguinte:
[root@standdg ~]# hostname standdg.oracle.com [root@standdg ~]# ping bancodg PING bancodg.oracle.com (20.0.0.10) 56(84) bytes of data. 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=1 ttl=64 time=0.181 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=2 ttl=64 time=0.363 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=3 ttl=64 time=0.278 ms --- bancodg.oracle.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.181/0.274/0.363/0.074 ms [root@standdg ~]# ping bancodg.oracle.com PING bancodg.oracle.com (20.0.0.10) 56(84) bytes of data. 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=1 ttl=64 time=0.134 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=2 ttl=64 time=0.247 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=3 ttl=64 time=0.379 ms --- bancodg.oracle.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.134/0.253/0.379/0.100 ms
Criando o LISTENER
Aproveitando que as duas VMs estão ligadas e seus host atualizados, vamos aproveitar e criar o listener nelas. Para isso conecte com o usuário oracle em cada uma das máquina e realize os passos abaixo:
Execute o comando netca
Acima está apenas os passos da máquina DB Primary (bancodg), é necessário realizar os mesmos passos para a máquina DB Dataguard (standdg).
February 14, 2013
No dia seguinte em que publiquei a parte 1 da série sobre segurança de banco de dados, meu amigo Gerson Vasconcelos Jr. enviou através do e-mail um trabalho que havia feito na faculdade que poderia ajudar a fazer os próximos post de segurança, e realmente .. o documento é fantástico! Tem várias notas muito bem explicadas de como configurar o Oracle para trabalhar de forma segura!
O Gerson para quem não sabe, além de ser um grande amigo e um grande DBA que essa carreira deu o privilégio de conhecer, o cara também é blogueiro, seu blog é o http://www.diaadiaoracle.com.br/ e ele escreve também no Grupo de Profissionais Oracle no blog Dia a Dia Oracle.
Como ele mesmo disse no e-mail: “Conhecimento é a única coisa que quando você divide, se multiplica!”, aqui está o trabalho e a apresentação do Gerson (claro pedi a permissão dele para divulgar): http://flaviosoares.com/docs/security/trabalho_gerson
Entre as notas mencionadas por Gerson no trabalho, a que achei mais interessante foi sobre o parâmetro ULT_FILE_DIR, para quem não sabe esse parâmetro pode destruir seu ambiente! Caso o usuário oracle tenha privilégio, você pode criar um arquivo através do utilitário utl_file bem em cima de um arquivo crítico do SO, ae já sabe … adeus servidor! Mas, como contornar isso? Leia o trabalho, que lá o Gerson explica melhor!
Gersão, está devendo uma passada aqui em São Paulo para a gente tomar uma ein! 
January 30, 2013
…
Na primeira parte da nossa série, foi criada a máquina virtual chamada de “DB Primary”, ela será nosso Primary Database (está lembrado?). Temos somente o Oracle Linux instalado nessa máquina, precisamos hoje criar as configurações do pré-requisitos e instalarmos o Oracle Database 11g nessa máquina.
Após essa máquina virtual está totalmente configurada e instalada, iremos criar um clone desse disco para a criação do Dataguard Database, mais isso faremos juntos na parte 3.
Hoje nossa missão é realizar os pré requisitos e instalar o Oracle Database 11gR2, para isso tenha em mãos o binário de instalação do Oracle 11g R2. Vou utilizar aqui a versão 11.2.0.3, porém fica a seu critério que release 11g R2 utilizar.
Com a máquina virtual ligada, clique no disco vazio que fica na barra de status da VM (veja o marco em vermelho).
Após ter clicado, irá mostrar os discos ISO disponíveis, provavelmente o Oracle Linux estará, caso não esteja selecione através da opção “Choose a virtual CD/DVD disk file …”
Feito isso, você verá a ISO do Oracle Linux sendo montada como um CDROM na máquina Virtual:
Veja que a ISO está apontando para o diretório /media/Enterprise Linux dvd 20100405.
[root@bancodg ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 19G 3.0G 15G 17% / tmpfs 502M 0 502M 0% /dev/shm /dev/hda 3.4G 3.4G 0 100% /media/Enterprise Linux dvd 20100405
Entre no diretório da ISO.
[root@bancodg ~]# cd /media/Enterprise\ Linux\ dvd\ 20100405/Server/ [root@bancodg Server]#
É necessário agora realizar a instalação dos pacotes rpm Linux. Seja abaixo a instalação de cada um deles.
[root@bancodg Server]# rpm -ivh binutils-2.17.50.0.6-14.el5.x86_64.rpm warning: binutils-2.17.50.0.6-14.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package binutils-2.17.50.0.6-14.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh compat-libstdc++-33-3.2.3-61.x86_64.rpm warning: compat-libstdc++-33-3.2.3-61.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package compat-libstdc++-33-3.2.3-61.x86_64 is already installed [root@bancodg Server]# rpm -ivh compat-libstdc++-33-3.2.3-61.i386.rpm warning: compat-libstdc++-33-3.2.3-61.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package compat-libstdc++-33-3.2.3-61.i386 is already installed [root@bancodg Server]# rpm -ivh elfutils-libelf-0.137-3.el5.x86_64.rpm warning: elfutils-libelf-0.137-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package elfutils-libelf-0.137-3.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-2.5-49.x86_64.rpm warning: glibc-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-2.5-49.i686.rpm warning: glibc-2.5-49.i686.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-2.5-49.i686 is already installed [root@bancodg Server]# rpm -ivh glibc-common-2.5-49.x86_64.rpm warning: glibc-common-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-common-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh ksh-20100202-1.el5.x86_64.rpm warning: ksh-20100202-1.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package ksh-20100202-1.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libaio-0.3.106-5.x86_64.rpm warning: libaio-0.3.106-5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libaio-0.3.106-5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libaio-0.3.106-5.i386.rpm warning: libaio-0.3.106-5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libaio-0.3.106-5.i386 is already installed [root@bancodg Server]# rpm -ivh libgcc-4.1.2-48.el5.x86_64.rpm warning: libgcc-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libgcc-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libgcc-4.1.2-48.el5.i386.rpm warning: libgcc-4.1.2-48.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libgcc-4.1.2-48.el5.i386 is already installed [root@bancodg Server]# rpm -ivh libstdc++-4.1.2-48.el5.x86_64.rpm warning: libstdc++-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libstdc++-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libstdc++-4.1.2-48.el5.i386.rpm warning: libstdc++-4.1.2-48.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libstdc++-4.1.2-48.el5.i386 is already installed [root@bancodg Server]# rpm -ivh make-3.81-3.el5.x86_64.rpm warning: make-3.81-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package make-3.81-3.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh unixODBC-2.2.11-7.1.x86_64.rpm warning: unixODBC-2.2.11-7.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC ########################################### [100%] [root@bancodg Server]# rpm -ivh unixODBC-2.2.11-7.1.i386.rpm warning: unixODBC-2.2.11-7.1.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC ########################################### [100%] [root@bancodg Server]# rpm -ivh unixODBC-devel-2.2.11-7.1.x86_64.rpm warning: unixODBC-devel-2.2.11-7.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC-devel ########################################### [100%] [root@bancodg Server]# rpm -ivh unixODBC-devel-2.2.11-7.1.i386.rpm warning: unixODBC-devel-2.2.11-7.1.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC-devel ########################################### [100%] [root@bancodg Server]# rpm -ivh elfutils-libelf-devel-static-0.137-3.el5.x86_64.rpm warning: elfutils-libelf-devel-static-0.137-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package elfutils-libelf-devel-static-0.137-3.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh gcc-4.1.2-48.el5.x86_64.rpm warning: gcc-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package gcc-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh gcc-c++-4.1.2-48.el5.x86_64.rpm warning: gcc-c++-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package gcc-c++-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-devel-2.5-49.x86_64.rpm warning: glibc-devel-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-devel-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-devel-2.5-49.i386.rpm warning: glibc-devel-2.5-49.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-devel-2.5-49.i386 is already installed [root@bancodg Server]# rpm -ivh glibc-headers-2.5-49.x86_64.rpm warning: glibc-headers-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-headers-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh kernel-headers-2.6.18-194.el5.x86_64.rpm warning: kernel-headers-2.6.18-194.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package kernel-headers-2.6.18-194.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libgomp-4.4.0-6.el5.x86_64.rpm warning: libgomp-4.4.0-6.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libgomp-4.4.0-6.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libstdc++-devel-4.1.2-48.el5.x86_64.rpm warning: libstdc++-devel-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libstdc++-devel-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh sysstat-7.0.2-3.el5.x86_64.rpm warning: sysstat-7.0.2-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package sysstat-7.0.2-3.el5.x86_64 is already installed
Com todos os pacotes instalados, vamos as configurações de kernel do sistema operacional. Faça as seguintes operações:
[root@bancodg ~]# vi /etc/sysctl.conf
#Oracle Settings
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
Para ativa-lós execute o sysctl como abaixo:
[root@bancodg ~]# sysctl -p
Hora de configurar os limits do Oracle, para isso adicione as seguintes linhas no arquivo /etc/security/limits.conf
[root@bancodg ~]# vi /etc/security/limits.conf
#Oracle Settings
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
Edite também as limites do arquivo /etc/profile.
[root@bancodg ~]# vi /etc/profile
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -u 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Configure agora o arquivo /etc/pam.d/login com a linha abaixo:
[root@bancodg ~]# vi /etc/pam.d/login
session required pam_limits.so
Pronto, limites e demais configurações feitas. Vamos a validação do host que é muito importante para um ambiente DataGuard.
[root@bancodg ~]# vi /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
20.0.0.10 bancodg.oracle.com bancodg
Checando o hostname:
[root@bancodg ~]# hostname bancodg.oracle.com [root@bancodg ~]# hostname -i 20.0.0.10
Com as configurações acima, vamos agora criar o usuário oracle:
[root@bancodg ~]# groupadd oinstall [root@bancodg ~]# groupadd dba [root@bancodg ~]# useradd -g oinstall -G dba oracle
Altere a senha do usuário também:
[root@bancodg ~]# passwd oracle Changing password for user oracle. New UNIX password: oracle BAD PASSWORD: it is based on a dictionary word Retype new UNIX password: oracle passwd: all authentication tokens updated successfully.
Vamos agora a criação do diretório. Faça os seguintes comandos:
[root@bancodg ~]# mkdir -p /u01/app/oracle [root@bancodg ~]# chown -R oracle:oinstall /u01/
Pronto! As configurações todas ok.
Precisamos agora transferir o binário do Oracle para a máquina virtual. Caso você estiver em um ambiente windows, você pode utilizar o winscp. No meu caso vou utilizar o utilitário scp.
$ scp p10404530_112030_Linux-x86-64_1of7.zip p10404530_112030_Linux-x86-64_2of7.zip oracle@20.0.0.10:/u01/app/oracle/. oracle@20.0.0.10's password: *********** p10404530_112030_Linux-x86-64_1of7.zip 100% 01:28 ETA p10404530_112030_Linux-x86-64_2of7.zip 100% 01:45 ETA
Antes de instalar, precisamos é claro, descompactar os arquivos de instalação na máquina virtual.
Acesse novamente a VM do VirtualBox, e entre no caminho /u01/app/oracle (ou onde você deixou os binários) e utilize o unzip para descompactar os arquivos. Faça primeiro no arquivo 1 depois no arquivo 2, como abaixo:
[oracle@bancodg ~]$ cd /u01/app/oracle/ [oracle@bancodg oracle]$ ll total 2444440 -rwxr-xr-x 1 oracle oinstall 1358454646 Jan 16 22:44 p10404530_112030_Linux-x86-64_1of7.zip -rwxr-xr-x 1 oracle oinstall 1142195302 Jan 16 22:45 p10404530_112030_Linux-x86-64_2of7.zip [oracle@bancodg oracle]$ unzip p10404530_112030_Linux-x86-64_1of7.zip ... inflating: database/stage/properties/oracle.server_PE.properties inflating: database/stage/properties/sshConnectivity-usage.txt inflating: database/stage/properties/oracle.server_Custom.properties inflating: database/stage/properties/sPaths.properties inflating: database/stage/properties/ssh_system.properties inflating: database/stage/properties/oracle.server_SE.properties inflating: database/stage/properties/userPaths.properties inflating: database/welcome.html inflating: database/readme.html [oracle@bancodg oracle]$ unzip p10404530_112030_Linux-x86-64_2of7.zip ... inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup10.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup11.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup7.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup5.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup3.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup1.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup13.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup2.jar
Feito os passos acima, uma pasta chamada “database” será criada no atual diretório. Ela contém os binários de instalação do software Oracle Database 11gR2.
Vamos então para esse diretório, que no meu caso é o /u01/app/oracle/database:
LEMBRE-SE VOCÊ DEVE ESTAR COM O USUÁRIO ORACLE CONECTADO NA MÁQUINA VIRTUAL
Dispare o runInstaller, como na Imagem acima.
O runInstaller irá abrir uma janela de utilitário de passo a passo de instalação do software. Seguiremos os passos:
Primeiro, desmarque a opção de receber updates via My Oracle Support.
Um aviso será mostrado, pode ignora-ló e continue.
Por ser um ambiente totalmente feito para teste, vamos novamente ignorar os updates. Para isso clique em Skip software updates
Aqui, temos que selecionar o tipo da instalação. Vamos por enquanto somente instalar somente o software Oracle Database 11gR2.
Selecione opção Enterprise. Lembrando para usar o Oracle Dataguard, é obrigatório e imprescindível que a versão seja Enterprise Edition. Por isso ATENÇÃO, selecione a versão ENTERPRISE EDITION para essa instalação.
Define aqui a localização das variáveis ORACLE BASE e ORACLE_HOME.
Nesse momento é realizado um checklist completo do ambiente Oracle sobre as possíveis falhas de pré requisitos. No nosso caso, ele informou somente a falta de memória. Por ser um ambiente criado somente com a finalidade de estudo, podemos deixar a memória da máquina baixa (por motivos óbvios), porém em ambientes de produção nunca ignore tais erros.
Aqui é informado um resume de todas as configurações selecionadas.
Início da instalação …
É informado agora, para rodarmos dois scripts com o usuário root. Simplesmente assim: conecte como root e execute os dois.
[root@bancodg ~]# whoami root [root@bancodg ~]# /u01/app/oraInventory/orainstRoot.sh Changing permissions of /u01/app/oraInventory. Adding read,write permissions for group. Removing read,write,execute permissions for world. Changing groupname of /u01/app/oraInventory to oinstall. The execution of the script is complete.
Agora o segundo
[root@bancodg ~]# whoami
root
[root@bancodg ~]# /u01/app/oracle/product/11.2.0/dbhome_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/dbhome_1
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Creating /etc/oratab file...
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.
Fim da instalação
Com a conclusão da parte 2, temos a máquina virtual criada com o Oracle Database e todos os pré-requisitos feitos.
Vamos somente agora, adicionar as variáveis de ambiente da máquina DB Primary. Com o usuário oracle conectado, edite o arquivo ˜/.bash_profile e adicione as seguintes linhas:
[oracle@bancodg ~]$ vi ~/.bash_profile # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/bin export PATH export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 export ORACLE_SID=orcl export PATH=$ORACLE_HOME/bin:$PATH [oracle@bancodg ~]$
Agora ative as variáveis com o comando:
[oracle@bancodg ~]$ . ~/bash_profile
Na próxima parte, estarei realizando a cópia dessa VM ponta, para poder criar a máquina em um outro projeto.
January 12, 2013
Parte 01 – 07_DICTIONARY_ACCESSIBILITY
…
Encontrando os password default
Não é novidade nenhuma que existem várias contas de usuários padrão no banco de dados Oracle, alguns deles até são criados com privilégios administrativos.
Usuários padrão são criados no momento da criação do banco e claro, são registrados sem uma senha e já vem bloqueado por default, exceto para SYS e SYSTEM que são contas administrativas que quando criadas através do CREATE DATABASE, se não definidas as senhas, elas devem ficar:
SYS : CHANGE_ON_INSTALL)
SYSTEM : MANAGER
Se você acha que os usuários default do Oracle é uma lista pequena, está enganado, aqui é alguns dos usuários padrão que são instalado sempre que um banco ou uma feature do banco é instalada. Por exemplo, o usuário XDB somente é instalado quando o Oracle XMLDB é instalado:
SYS SYSTEM SYSMAN OUTLN TSMSYS WKSYS SCOTT ADAMS JONES WKPROXY OLAPSYS OWBSYS CLARK BLAKE HR OE SH DEMO ANONYMOUS CSMIG CTXSYS DBSNMP DIP DMSYS DSSYS EXFSYS LBACSYS MDSYS ORACLE_OCM ORDPLUGINS ORDSYS PERFSTAT XDB MGMT_VIEW SI_INFORMTN_SCHEMA
Porém para alguns deles (quase todos), existe uma senha padrão definida, como o famoso usuário SCOTT que possuí a senha padrão definida como TIGER.
Muitos ambientes Oracle tem o usuário SCOTT criado (e provavelmente até com a senha padrão definida), o que deixa o banco de dados muito vulnerável, imagina que com uma senha padrão definida, qualquer um a qualquer momento pode acessar o seu banco, somente acessando essa conta.
Ok, mais como me livro disto? Qual é a maneira de descobrir se os usuários na lista acima está com a senha padrão habilitada?
Somente a view DBA_USERS_WITH_DEFPWD pode te responder isso …
Logado no SQL*Plus com uma conta administrativa, execute a seguinte consulta de encontra a view DBA_USERS_WITH_DEFPWD
SQL> SELECT * FROM DBA_USERS_WITH_DEFPWD; USERNAME ------------------------------ DIP OUTLN ORACLE_OCM APPQOSSYS SQL> select username, account_status from dba_users where username in (select username from dba_users_with_defpwd); USERNAME ACCOUNT_STATUS ------------------------------ -------------------------------- APPQOSSYS EXPIRED & LOCKED ORACLE_OCM EXPIRED & LOCKED DIP EXPIRED & LOCKED OUTLN OPEN
A primeira consulta, mostra que temos a lista completa dos usuários em que a senha padrão está definida. Na segunda consulta, é informado que apenas o usuário OUTLN que tem uma senha padrão está com o status da conta habilitado.
Mesma com uma conta bloqueada, deixar o usuário com uma senha padrão pode ser muito perigoso, imagina se alguém habilita uma dessas contas sem querer e não troca a senha?
Para mudar a senha não é segredo:
SQL> PASSWORD OUTLN Changing password for OUTLN New password: ********* Retype new password: ************ Password changed
São maneiras simples como essa que podem te livrar de uma dor de cabeça incrível. O DBA devem estar atento a tudo, inclusive a pequenos detalhes como este. Nem quero pensar que uma conta dessas caia em mãos erradas, imagina que uma conta dessas com privilégio administrativo, o de create/drop tablespaces por exemplo, esteja com a conta habilitada e password default e algum abelhudo consegue conectar com essa conta, já penso o estrago? …
É! … você pode dar adeus ao seu banco e rezar para ter backup …
January 9, 2013
Já ouviram falar de OSWatcher? LTOM? SQLTXPLAIN e OPDG?
Bom, se vocês nunca ouviram falar dessas ferramentas chegou a hora de conhece-las.
A nota do metalink 438452.1 mostra essas e diversas outras ferramentas sobre performance tuning.
Bom apetite, aproveitem
December 12, 2012
Só nós DBA’s sabem as inúmeras funções, sintaxes e comandos que precisamos decorar no nosso dia a dia e isso não é uma tarefa fácil, além do que, as soluções sempre precisam ser rapidamente propostas. Por isso que gosto de facilitar as coisas sempre que posso, assim como esse script, que além de simples ele realiza é uma formarápida os passos que nem sempre são lembrados, isso evita aquele tempão gasto procurando na documentação a sintaxe exata de tal procedimento. Qual DBA que nunca passou por isso que atire a primeira pedra!
O objetivo principal do script é facilitar a execução do Oracle Segment Advisor, de uma forma bem simples, apenas três argumentos e nada mais e o melhor de tudo: não é preciso criar qualquer tipo de objeto no banco de dados, todo trabalho é executado através de um bloco anônimo de PLSQL e o único requisito aqui é o bom e velho SQL*Plus.
Você pode conferir a primeira versão (sim, próximas poderão surgir) você pode fazer aqui.
Como usar Segment Advisor Script?
SYNTAX: { @run_sa “Owner Segment” “Segment Name” “Segment Type” }
Ele não precisa nada mais além do que três argumento:
1. “Owner Segment” : O primeiro representa o nome do owner do segmento.
2. “Segment Name”: O segundo representa o nome do segmento.
3. “Segment Type”: O terceiro representa o tipo do segmento. Que pode ser um TABLE, INDEX etc …
Usando o Segment Advisor Script
Para explicar melhor vamos a um teste prático.
Primeiro de tudo, precisamos de uma tabela grande favorável para o teste que vamos fazer, para isso criei a tabela chamada TBIG dentro do schema FSOARES.
FSOARES@dbtst> create table tbig as select * from dba_source; Table created. FSOARES@dbtst> insert into tbig (select * from tbig); 633054 rows created. FSOARES@dbtst> / 1266108 rows created. FSOARES@dbtst> / 2532216 rows created. ... FSOARES@dbtst> commit; FSOARES@dbtst> @size tbig SEGMENT_NAME SEGMENT_TYPE SIZE_MB ------------------------------ ------------------ --------------- TBIG TABLE 5,244.00
Pronto, temos agora uma tabela de 5G que está perfeita para o nosso teste. Vamos ver quantos registros temos:
FSOARES@dbtst> set timing on
FSOARES@dbtst> select count(*) from tbig;
COUNT(*)
----------
40515456
1 row selected.
Elapsed: 00:04:08.21
Ok, temos cerca de 40515456 registros e levamos cerca de 4 minutos para sabermos isso. Vamos agora apagar uns 98% dessa tabela deixando apenas alguns milhares de registro. Para fazer essa operação mais racional, quero descobrir quantos registros tenho por usuário nessa tabela, afim de deixar apenas os menores owners:
FSOARES@dbtst> select count(*), owner from tbig group by owner order by 1;
COUNT(*) OWNER
---------- ------------------------------
576 IX
576 OUTLN
1088 PM
2176 FLOWS_FILES
2176 HR
2880 SYSTEM
13696 OE
14912 ORDPLUGINS
19392 WMSYS
70464 EXFSYS
183808 ORACLE_OCM
230528 DBSNMP
231552 ORDSYS
548288 XDB
731264 OLAPSYS
1258816 CTXSYS
1340416 MDSYS
2624256 APEX_030200
9466112 SYS
23772480 SYSMAN
20 rows selected.
Elapsed: 00:01:14.06
FSOARES@dbtst> delete tbig where owner NOT IN ('IX', 'OUTLN');
40514304 rows deleted.
Elapsed: 00:29:57.41
FSOARES@dbtst> commit;
Commit complete.
Elapsed: 00:00:00.01
Aqui, a nossa tabela TBIG está somente com os dados usuário IX e OUTLN, o resto dos outros usuário foi simplesmente apagado. Bom como temos agora apenas alguns registros vamos realizar aquele mesmo count para ver o a quantidade de registro, vamos ver agora o quanto tempo levará. Primeiro é claro, vamos remover a consulta do nosso cache.
FSOARES@dbtst> alter system flush shared_pool;
System altered.
FSOARES@dbtst> alter system flush buffer_cache;
System altered.
FSOARES@dbtst> select count(*) tbig
COUNT(*)
----------
1152
1 row selected.
Elapsed: 00:03:53.93
Temos agora cerca de mil registros e levamos quase o mesmo tempo para realizar o count da tabela quando ela estava com mais de 40 milhões de registro!? Como isso pode ser? Tivemos o mesmo tempo para contar de 0 a 1152 e de 0 a 40 milhões?
Bom, sem dúvidas há alguma coisa de errado com nosso segmento de tabela TBIG. É aí que entra o Segment Advisor, que vai nos aconselhar o que fazer com esse segmento.
Veja como é simples:
FSOARES@dbtst> @run_sa fsoares tbig table --------------------------------------------------------------------------------- -- Segment Adviser Script v1.0 by Flavio Soares ( http://flaviosoares.com ) Running the Segment Advisor for Segment Owner : FSOARES Segment Name: TBIG Segment Type: TABLE Segment Advisor successfuly completed For delete the task TaskName_FSOARES_cxdnLahXMf run: SQL> exec dbms_advisor.delete_task('TaskName_FSOARES_cxdnLahXMf'); -- Showing the Segment Advice Recommendations for the object "table" "fsoares" "tbig" TABLESPACE_NAME : USERS SEGMENT_OWNER : FSOARES SEGMENT_NAME : TBIG SEGMENT_TYPE : TABLE PARTITION_NAME : ALLOC_MB : 5,244.00 RECLAIM_MB : 4,567.54 USED_MB : 676.46 PCT_SAVE : 87 % RECOMMENDATIONS : Enable row movement of the table FSOARES.TBIG and perform shrink, estimated savings is 4789413285 bytes. SOLUTION 1 : alter table "FSOARES"."TBIG" shrink space SOLUTION 2 : alter table "FSOARES"."TBIG" shrink space COMPACT SOLUTION 3 : alter table "FSOARES"."TBIG" enable row movement ---------------------------------------------------------------------------------
Observe a recomendação, ele sugere realizar um shrink na tabela que ganharemos com isso cerca de 87% de espaço que hoje não está sendo utilizado. Opa! … é 87% é um bom ganho, então vamos aplicar as recomendações sugeridas.
FSOARES@dbtst> alter table "FSOARES"."TBIG" enable row movement; Table altered. FSOARES@dbtst> alter table "FSOARES"."TBIG" shrink space; Table altered.
Após as recomendações aplicadas, vamos agora executar novamente o count de encontro a tabela TBIG e observar o tempo:
FSOARES@dbtst> alter system flush shared_pool;
System altered.
FSOARES@dbtst> alter system flush buffer_cache;
System altered.
FSOARES@dbtst> select count(*) from tbig;
COUNT(*)
----------
1152
1 row selected.
Elapsed: 00:00:00.01
Depois da recomendação aplicada, o tempo simplesmente caiu para 0.01 segundos.
Viu como ficou bem mais simples utilizar o Segment Advisor agora com o run_sa.sql
Com apenas três argumentos e já temos nossas recomendações.
FSOARES@dbtst> @run_sa fsoares tbig table --------------------------------------------------------------------------------- -- Segment Adviser Script v1.0 by Flavio Soares ( http://flaviosoares.com ) Running the Segment Advisor for Segment Owner : FSOARES Segment Name: TBIG Segment Type: TABLE Segment Advisor successfuly completed For delete the task TaskName_FSOARES_cxdnLahXMf run: SQL> exec dbms_advisor.delete_task('TaskName_FSOARES_cxdnLahXMf'); -- Showing the Segment Advice Recommendations for the object "table" "fsoares" "tbig" TABLESPACE_NAME : USERS SEGMENT_OWNER : FSOARES SEGMENT_NAME : TBIG SEGMENT_TYPE : TABLE PARTITION_NAME : ALLOC_MB : 5,244.00 RECLAIM_MB : 4,567.54 USED_MB : 676.46 PCT_SAVE : 87 % RECOMMENDATIONS : Enable row movement of the table FSOARES.TBIG and perform shrink, estimated savings is 4789413285 bytes. SOLUTION 1 : alter table "FSOARES"."TBIG" shrink space SOLUTION 2 : alter table "FSOARES"."TBIG" shrink space COMPACT SOLUTION 3 : alter table "FSOARES"."TBIG" enable row movement ---------------------------------------------------------------------------------
Dúvidas, melhorias, bugs, recomendações serão muito bem vindas!
Um abraço e aproveitem!
December 11, 2012
Será o lançamento do Oracle 12c amanhã?
No dia 12/12/2012 ?
Será?
Só nos basta esperar …
December 11, 2012
O objetivo não é assustar mais o de sempre informar.
Bug 4421376 – Dump (kgldpo) after ALTER TYPE .. RESET
De acordo com a Oracle, existem casos em que quando o “ALTER TYPE RESET;” é executado podem ocorrer corrupção no dicionário de dados do seu banco, isso mesmo você “pode” ter uma corrupção no seu banco!
Para confirmar o problema, basta ver a mensagem kgldpo no seu dump quando um reset é disparado. Oracle acredita que as versões abaixo da 11g podem ser afetadas com esse problema, porém confirma apenas na versão 10.2.0.4.
Sempre consulte o Oracle Supporte para qualquer conselho.
Mais detalhes:
Bug 4421376 – Dump (kgldpo) after ALTER TYPE .. RESET [ID 4421376.8]
São esses tipos de problemas, que existe um intenso apelo por parte da Oracle para sempre manter o seu banco atualizado e com seus os patch em dias, podendo evitar assim problemas extremamente graves como este.
