GUOB TECH DAY / Groundbreakers Tour LATAM 2019

Galera,

Em 2019 ocorrerá a 10ª edição do GUOB Tech Day!

APROVEITE o Voucher de 20% de Desconto: NAO_PERCA_GUOB

Na sua décima edição, o GUOB vem recheado de excelente conteúdo e excelentes speakers!!

📌Contando com 9 salas e 3 Workshops, será o maior evento já realizado pelo GUOB no Brasil!

A minha palestra será sobre Oracle Exadata Cloud at Customer às 13:50h na SALA 1.

📌Quando: 10/08/2019

📌Onde:
Universidade Nove de Julho (UNINOVE) – Campus Vergueiro.
Rua Vergueiro, 235 – Liberdade – São Paulo-SP

📌Quanto?
https://lnkd.in/dbX7v3Q

📌Inscrições:
https://lnkd.in/d9n6Pyd

📌Grade Completa:
https://lnkd.in/dfwRihx

📌Será Filmado ou Transmitido Online?
Não

Participe da 10ª edição do GUOB TECH DAY. Faça sua inscrição ainda hoje, aproveite que o ingresso no segundo lote está com desconto !

CRS crash after upgrade to Oracle 12.2

vector illustration of Crazy man cartoon

Cai num bug “interessante” na última semana após a atualização para o Oracle 12.2

I have hit an interesting bug this week after upgrade to Oracle 12.2.

A nota Doc ID 2460394.1 tem os detalhes do bug mas basicamente sua base será reiniciada pelo CRS de tempos em tempos.

MOS note Bug 28298447: cluster crashed due to mellanox driver related issue (Doc ID 2460394.1) has the details but basically your cluster will bounce the DB from time to time.

Ou seja, se você tem um Exadata, atualize o kernel para a versão 4.1.12-94.8.5 antes de realizar o upgrade do banco para 12.2

So if you running an Exadata, upgrade the kernel to version 4.1.12-94.8.5 before upgrading db to 12.2.

Essa correção de kernel também está disponível nas versões 12.2.1.1.7 (ou superior) ou 18.1.5.0.0 (ou superior), ou seja, QFSDP abril/2018.

This kernel fix is also included on image version 12.2.1.1.7 (or higher) or 18.1.5.0.0 (or higher), or QFSDP from april/2018.

BUG 23300142 – Redo Transport Slave Process

A semana começou com o filesystem /u01 alarmando ocupação elevada. Iniciei então uma investigação para encontrar o que estava ocupando o disco.

My week started with a filesystem high occupation alarm. I then started looking for what was going on.

Utilizei o comando find abaixo para buscar por arquivos grandes:

I usually use the find command bellow to search for huge files:

find / -type f -size +800M -exec ls -lh {} \; | awk '{ print $NF ": " $5 }'

Bingo! encontrei o arquivo de trace do processo TT01 (Redo Transport Slave Process) consumindo 6Gb !

Yes ! found a trace file from process TT01 (Redo Transport Slave Process) consuming 6 Gb!

Olhando o conteúdo do arquivo, a mensagem:

Looking at the contents of the trace file the messages:

Error in determining current logfile for thread 1
ASYNC ignored current log: KCCLENAL clear thread open

era repetida continuamente.

was happening on an on.

Uma pesquisa rápida no MOS e confirmado mais um BUG para coleção: Bug 23300142 – TT background process trace file message: async ignored current log: kcclenal clear thread open (Doc ID 23300142.8)

A quick search on MOS and I have hit another BUG for my collection: Bug 23300142 – TT background process trace file message: async ignored current log: kcclenal clear thread open (Doc ID 23300142.8)

A correção está disponível nos patches:

Bug fix is included on patches:

12.2.0.1.170919 (Sep 2017) Database Release Update (DB RU)
12.1.0.2.180116 (Jan 2018) Database Proactive Bundle Patch
12.2.0.1.171017 (Oct 2017) Bundle Patch for Windows Platforms

 

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.

 

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