DBCA /LISTENER

Essa semana encontrei um erro durante a criação de um banco RAC no Oracle Database Appliance.

A mensagem de erro era:

“ERROR : /bin/su oracle -c “/opt/oracle/oak/onecmd/tmp/dbca-PRTCORP.sh” did not complete successfully. Exit code 1 #Step -1# “

e o log do DBCA mostrava a mensagem:

“Default Listener “LISTENER” is not configured in the Grid Infrastructure home.”

O erro na verdade foi meu 😦  .. já que eu alterei um pouco demais o ambiente.

Por que ? Configuração de algumas redes (VLANs) no ambiente.

Segundo o MOS 1198973.1, o DBCA procura pelo listener default LISTENER rodando na porta 1521 para completar a criação da base em ambientes com GridInfrastructure.

A correção foi simples: removi um listener e o criei novamente com o nome padrão LISTENER.

 

This week I got an error running DBCA to create a RAC DB on my Oracle Database Appliance.

The error message was:

“ERROR : /bin/su oracle -c “/opt/oracle/oak/onecmd/tmp/dbca-PRTCORP.sh” did not complete successfully. Exit code 1 #Step -1# “

and in DBCA log was reported:

“Default Listener “LISTENER” is not configured in the Grid Infrastructure home.”

It was actually my mistake 😦 .. because I end up changing the environment too much.

But why so many changes ? Well, I had to set up a few networks (VLANs) on this GI.

As stated by MOS 1198973.1, the dbca utility searches for a default listener named LISTENER and running on port 1521 in order to complete the database creation running on GridInfrastructure home.

To fix this issue I had to remove one listener and create a new one with the default listener name LISTENER.

DBSAT via ORACHK

A ferramenta DBSAT foi recentemente incorporada ao utilitário ORACHK, ou seja, por padrão as execuções do orachk também trarão as recomendações de segurança a serem aplicadas no ambiente.

É possível rodar o orachk e trazer somente as validações de segurança, para isso, utilize orachk -profile security.

Mais informações em:

Database Security Assessment Tool User Guide:

https://docs.oracle.com/cd/E76178_01/SATUG/toc.htm#SATUG-GUID-C7E917BB-EDAC-4123-900A-D4F2E561BFE9

MOS note: Oracle Database Security Assessment Tool (DBSAT) (Doc ID 2138254.1)

 

 

 

Oracle Data Guard Database Compare

Uma nova procedure chamada DBMS_DBCOMP.DBCOMP (disponível na 12.2), compara os blocos de dados armazenados no Primary DB e seu standby físico. A ferramenta busca por erros de disco que não podem ser detectados por outras ferramentas como, por exemplo, o utilitário DBVERIFY.

Veja que o proprio DataGuard já realiza a validação de corrupção de dados quentes (dados que são lidos ou alterados) tanto no Primary quanto no Standby.

Mas a nova ferramenta vai além pois valida também os dados frios, permitindo ao DBA ter confiança de que seu ambiente está livre de corrupções físicas.

Modo de utilização:

DBMS_DBCOMP.DBCOMP (datafile IN varchar2, outputfile IN varchar2, block_dump IN boolean);

Onde,

datafile – pode ser o número ou nome do datafile. Utilize ‘ALL’ para comparar todos os datafiles.

outputfile – define um prefixo para o nome do arquivo de saída. Por padrão o arquivo é gerado no diretório $ORACLE_HOME/dbs. É gerado um arquivo de saída por datafile.

block_dump – Parâmetro boleano para especificar se o conteúdo do bloco deve ser gravado no arquivo de saída quando um bloco não idêntico entre primary/standby for encontrado. False por padrão.

Exemplo: Execute no Primary.

exec sys.dbms_dbcomp.dbcomp(‘ALL’,’standbypdbComparison’, true);

e utilize a view V$SESSION_LONGOPS para acompanhar o progresso.

ORA 600 [krbb1cf_badblk] during RMAN backup

Se o seu backup começar a falhar com o erro ORA-600 [krbb1cf_badblk], aplique, inicialmente, as recomendações do MOS 2088954.1.

No meu caso, a solução de contorno aplicada foi executar o backup usando o comando BACKUP BLOCKS ALL DATABASE do rman.

Outro MOS que utilizei durante esse chamado foi o 1547088.2 – How to Upload Files to Oracle Support, onde você aprende a subir arquivos maiores do que 2Gb para o suporte.

Após 4 semanas chegou a confirmação: caímos no BUG 25429959, corrigido à partir da versão 12.1.0.2.170718.

 

Oracle dNFS

Nesse post vou demonstrar como configurar o Oracle dNFS para acessar um NFS e subir seus bancos.

Sobre o meu ambiente:

HW: Cisco UCS

Sistema Operacional: Oracle Linux 6.9

Oracle: 12.1.0.2.170418

NAS: Netapp

Conectividade: 10G

Vamos ao que interessa 🙂

Pare o banco, ative o dNFS e inicie a instance novamente.

Ativando o dNFS:

$ cd $ORACLE_HOME/rdbms/lib

$ make -f ins_rdbms.mk dnfs_on

Procure no alert pela string: Oracle instance running with ODM: Oracle Direct NFS ODM Library Version 3.0.

Crie o(s) diretório(s) como ponto de montagem para o NFS:

Ex: mkdir –p /mnt/sha1

Configure o fstab e monte o NFS

ex: 172.24.4.14:/TI_PROT_DEV_01  /mnt/sha1  nfs  rw,bg,hard,nointr,tcp,vers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0  0 0

Traduzindo:

<NFS IP>:<device> <mount point> nfs rw,bg,hard,nointr,tcp,vers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0  0 0

Para montar o NFS: mount /mnt/sha1

Pronto! Agora é só criar as tablespaces no NFS.

 

Links que recomendo a leitura para aprofundar o assunto:

Best Practices: How to Configure DNFS in Oracle Database (Doc ID 2246245.1)

Clone your dNFS Production Database for Testing (Doc ID 1210656.1)

DNFS Performance Monitoring (Doc ID 1556066.1)

How to configure DNFS to use multiple IPs (Doc ID 1552831.1)

https://bdrouvot.wordpress.com/2017/09/30/systemtap-and-oracle-rdbms-io-and-network-traffic/

https://kb.netapp.com/support/s/article/best-practices-to-configure-a-dnfs-client?language=en_US

https://martincarstenbach.wordpress.com/2014/07/09/setting-up-direct-nfs-on-oracle-12c/

https://docs.oracle.com/database/121/LADBI/post_inst_task.htm#LADBI5390

 

Patching EM13c

Para minha surpresa, após realizar o upgrade para o EM 13.2, os restarts no ambiente agora são diários 😦

Bom, começei então a procurar pelas atualizações do EM.

Após ler muitas notas no MOS, segue o resumo da ópera:

A recomendação é aplicar o último PSU (disponível de quatro em quatro meses) e se possível, aplicar também os BP, disponíveis mensalmente.

Os patches são cumulativos.

Vamos ao procedimento:

  1. atualizar o EM OMSPatcher através do patch 19999993
  2. atualizar o OPatch através do patch 6880880 (aplicar no OMS e Agent homes)
  3. aplicar último PSU – patch 25731746 (OMS-side)
  4. aplicar último BP – patch 26716235 (OMS-side)
  5. aplicar último BP – patch 26649994 (agent-side)

Obs: detalhe sobre como aplicar os patches estão no arquivo README.html de cada um dos patches.

Para verificar os patches instalados rode o comando: omspatcher lspatches

Referência:

Enterprise Manager 13.2 Master Bundle Patch List (Includes Plugins: 13.2.1, 13.2.2, 13.2.3) (Doc ID 2219797.1)

Atualização para o EM 13.2 – http://www.oracle.com/technetwork/pt/articles/cloudcomp/upgrade-emcloud-3941666-ptb.html

ODC Appreciation Day: LACP

odc

The ODC Appreciation Day was proposed by Tim Hall and you can find more information here: https://oracle-base.com/blog/2017/09/25/odc-appreciation-day-2017-thanksodc/

Link Aggregation Control Protocol (LACP), also known as 802.3ad is a methods of combining multiple physical network connections into one logical connection to increase throughput and provide redundancy in case one of the links should fail. The protocol requires both – the server and the switch(es) to have the same settings to allow LACP to work properly.

To configure LACP you need to change your bonding device configuration in /etc/sysconfig/network-scripts/ifcfg-bond0 similarly to this:

DEVICE=bond0
IPADDR=192.168.0.2
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
NM_CONTROLLED=no
MTU=9000
BONDING_OPTS="mode=4 miimon=100 downdelay=5000 updelay=5000 num_grat_arp=100 xmit_hash_policy=layer3+4 lacp_rate=1"

The key here is setting the MTU=9000 and establishing the transmit hash policy as layer3+4. This transmit policy is intended to more-evenly distribute the traffic across the physical links of the bonded device.

This is is the preferred mode of network bonding, but requires that the network is configured correctly on the switch.

You can then test the performance using iperf linux tool.

More information on https://wiki.linuxfoundation.org/networking/bonding

 

 

 

 

snapshot-based backup

Do it before applying Oracle PSU/BP patches or change a configuration.

Steps taken:

lvcreate -L1G -s -c 32K -n root_snap /dev/VGExaDb/LVDbSys1

e2label /dev/VGExaDb/root_snap DBSYS_SNAP

mkdir /mnt/snap/root
mount /dev/VGExaDb/root_snap /mnt/snap/root -t ext4

mount -l

lvcreate -L5G -s -c 32K -n u01_snap /dev/VGExaDb/LVDbOra1

e2label /dev/VGExaDb/u01_snap DBORA_SNAP

mkdir -p /mnt/snap/u01

mount /dev/VGExaDb/u01_snap /mnt/snap/u01 -t ext4

mount -l

umount /mnt/bkp_tst

cd /mnt/snap/

tar -pjcvf /mnt/bkp_dump/root_exaoradb01.tar.bz2 * /boot –exclude /mnt/bkp_dump/root_exaoradb01.tar.bz2 –exclude /mnt/bkp_dump > /tmp/bkptar.stdout 2> /tmp/bkptar.stderr

— umount snapshots
cd /

umount /mnt/snap/u01
umount /mnt/snap/root

lvremove /dev/VGExaDb/u01_snap
lvremove /dev/VGExaDb/root_snap

Documentation:

http://www.toadworld.com/platforms/oracle/w/wiki/11617.exadata-create-snapshot-based-backup-of-oracle-linux-database-server

http://docs.oracle.com/cd/E80920_01/DBMMN/maintaining-exadata-database-servers.htm#DBMMN21377