How-To on Café Com Cloud

Um how-to da AWS

Wed, 14 Nov 2018 17:01:29 -0200

Eu sei que vocês ouviram falar do outage da Amazon numa loja específica durante a migração de Oracle pra Aurora. Mas o que vocês não ouviram é: eles já migraram 88% do parque Oracle deles pra Aurora, e o único problema real foi o que veio a público (claro).

Então, se você quer dar uma olhada nesse how-to, como usar o serviço AWS DMS, pega um café e segue o link abaixo:

https://aws.amazon.com/blogs/database/best-practices-for-migrating-an-oracle-database-to-amazon-rds-postgresql-or-amazon-aurora-postgresql-migration-process-and-infrastructure-considerations/

Falamos,

Install do 18c on-premises - primeiras impressões

Mon, 10 Sep 2018 18:35:18 -0300

E aí pessoal,

Algumas coisas mudaram no 18c. Hoje vou explicar minhas primeiras impressões desse produto bem novinho on-premises e algumas comparações com versões anteriores (PS: eu classifiquei cada tópico antes de começar a falar.. espero ajudar vocês no próximo upgrade)

Download: se você baixar pelo Oracle OTN, vai notar que tem só um zip pro Oracle database e um zip pro install do grid.
Install: agora você tem que descompactar todo o conteúdo dentro do Oracle_HOME <- eles chamam esse novo jeito de “Simplified Image-based Oracle Database Installation”
Install: o runInstaller foi substituído pelo gridSetup.sh (no caso de install do Grid) e pro Installer de database você ainda precisa executar o runInstall.sh
Install: você vai precisar de pelo menos uma máquina com 8 GB de RAM pra instalar grid / database.
Install: pro installer de database, agora você tem as duas opções de install (como no Installer do 10g) - você pode escolher instalar Enterprise ou Standard Edition 2.
Install: agora você pode escolher no install do database o TFA durante a execução do root.sh.

Falamos :-)

Backup na era cloud - o que está mudando?

Wed, 20 Dec 2017 13:07:05 -0200

E aí, beleza!

Espero que esse post te encontre bem. Esses dias um dos meus clientes me pediu pra aconselhar ele sobre procedimentos e soluções de backup/restore num ambiente novo rodando na AWS.

Bancos de produção vão rodar em instâncias EC2, em Oracle com BYOL (bring your own license). O cliente está pensando em soluções de EBS (Elastic Block Storage) ou S3 (Simple Storage Service).

Snapshots no mundo Oracle normalmente são usados em conjunto com operações de begin/end backup. Se você tira só 1 snapshot por dia, e não está disposto a perder 24h de dados commitados, você precisa ter uma segunda estratégia de backup. Existe um produto oferecido pela N2WS que é bem incrível pra orquestrar, agendar e controlar os snapshots, você pode configurar pra tirar uma foto a cada 5 min, o que geralmente é menor que um RPO de negócio. Mas e quanto a uma corrupção lógica, um delete errado feito no fim de semana passado? Como restaurar isso? Você precisa reter snaps por uma semana, talvez um mês, talvez um ano, restaurar esse snap em outra instância EC2 e restaurar os dados manualmente. Parece caro, né?

O jeito do mundo ideal, vindo da documentação, é fazer deploy do OSBCS Oracle Secure Backup Cloud Service. Essa opção (paga) te dá a habilidade de usar S3 como tape, então ajustes mínimos precisam ser feitos pra migrar sua estratégia de backup pra cloud. Você precisa configurar e instalar o OSBCS em cada instância EC2, ajustar seus channels pra usar o OSBCS, e tá pronto pra ir! Retention do RMAN, catalog, tudo flui bonito se você escolher pagar por essa opção. Como o OSBCS é cobrado? Por Channel.

Então, se você tem 100 bancos, você pode comprar por exemplo 10 channels, e fazer 1 backup por vez com 10 channels, ou 10 backups por vez com 1 channel, ou 2 backups por vez com 5 channels, ou 5 backups por vez com 2 channels, ou.. você pegou a ideia.

Comentários são bem vindos =]

Falamos,

Hang.

12cR1 + Suse 12 SP2 = dá uma olhada nesse post

Sat, 10 Jun 2017 22:19:15 -0300

Hoje eu enfrentei um problema estranho durante um HAS 12.1.0.2 no Suse 12 SP2 pra um cliente.

Tudo correu bem durante o runInstaller, mas o roothas.pl falhou com o seguinte erro:

SERVER_BLA:/u01/grid/12.1.0.2 # /u01/grid/12.1.0.2/perl/bin/perl -I/u01/grid/12.1.0.2/perl/lib -I/u01/grid/12.1.0.2/crs/install /u01/grid/12.1.0.2/crs/install/roothas.pl Using configuration parameter file: /u01/grid/12.1.0.2/crs/install/crsconfig_params LOCAL ADD MODE Creating OCR keys for user ‘ora12c’, privgrp ‘dba’.. Operation successful. LOCAL ONLY MODE Successfully accumulated necessary OCR keys. Creating OCR keys for user ‘root’, privgrp ‘root’.. Operation successful. CRS-4664: Node SERVER_BLA successfully pinned. 2017/06/10 00:46:42 CLSRSC-330: Adding Clusterware entries to file ‘oracle-ohasd.service’

PRCR-1006 : Failed to add resource ora.ons for ons PRCR-1115 : Failed to find entities of type resource type that match filters (TYPE_NAME ends .type) and contain attributes CRS-0184 : Cannot communicate with the CRS daemon. 2017/06/10 00:47:04 CLSRSC-180: An error occurred while executing the command ‘srvctl add ons’ (error code 0)

2017/06/10 00:47:55 CLSRSC-115: Start of resource ‘ora.evmd’ failed

2017/06/10 00:47:55 CLSRSC-202: Failed to start EVM daemon

Esse PRCR-1006 me deixou doido. No final, depois de longas horas garimpando a web + metalink + cafeína, descobri que você precisa:

vi /etc/ld.so.conf e adicionar /lib64/noelision no topo do arquivo.

O arquivo deve ficar assim depois do vi:

SERVER_BLA:/u01/grid/12.1.0.2/crs/install# cat /etc/ld.so.conf /lib64/noelision /usr/local/lib64 /usr/local/lib include /etc/ld.so.conf.d/*.conf

E então adiciona o symlink no GI_HOME:

SERVER_BLA:/u01/grid/12.1.0.2/lib# lns -s /lib64/noelision/libpthread-2.22.so libpthread.so.0

E só depois disso roda o root.sh/roothas.pl. Se você está lendo esse post, provavelmente já executou o roothas.pl (=[ infelizmente). Então você precisa fazer deconfigure primeiro, executar os passos acima, e então executar o roothas.pl de novo.

Depois disso, a felicidade volta =]

***Update***

Quando for fazer patching no GI home, remove o symlink criado, aplica o patch, e refaz o symlink.

Feedbacks são sempre bem vindos! Falamos,

Hang,

Usando oradebug - eventos 10053 e 10046

Mon, 27 Feb 2017 12:00:06 -0300

E aí, beleza! Espero que esse artigo te encontre bem. Hoje a gente vai falar sobre oradebug, essa pequena maravilha do Oracle, e como setar os eventos 10046 e 10053 pra troubleshooting de performance.

Primeiro de tudo, o que é oradebug?

Oradebug é uma ferramenta do sqlplus, destinada só pra pessoal de suporte Oracle. Mas ela pode ser bem útil em um monte de situações. Você pode usar pra setar eventos específicos de troubleshooting, usar pra diagnosticar qual interface seu RAC está usando pras mensagens de interconnect, usar pra executar um hanganalyze (o comando, não eu, beleza? =]), system state dumps, errorstack dumps, e a lista vai longe.

Como eu uso?

Primeiro de tudo, você precisa atachar o oradebug a uma sessão/processo específico.

Usando o ospid:

Pega o os pid pro processo, normalmente com o comando ps, ou pegando a thread em ambiente Windows. Com o ospid (nesse exemplo 1177)

oradebug setospid 1177;

Se você tentar atachar o oradebug a um processo inativo, você vai receber:

SQL> oradebug setospid 13050; ORA-00072: process “13050” is not active

Se tudo correu bem, você vai receber:

SQL> oradebug setospid 16792; Oracle pid: 150, Unix process pid: 16792, image: oracle@BLASERVER12

Usando o SID pra atachar o oradebug:

Primeiro de tudo você precisa descobrir o orapid da sessão, rodando o sql abaixo:

select p.pid orapid from v$process p, v$session s where s.sid = &SID and p.addr = s.paddr /

Exemplo:

SQL> select p.pid orapid from v$process p, v$session s where s.sid = &SID and p.addr = s.paddr / 2 3 4 5 6 Enter value for sid: 651 old 4: where s.sid = &SID new 4: where s.sid = 651

ORAPID ———- 152

SQL> oradebug setorapid 152; Oracle pid: 152, Unix process pid: 5392, image: oracle@BLASERVER12 (TNS V1-V3)

Tá pronto!

Setando o evento 10046

oradebug event 10046 trace name context forever, level 12;

Setando o evento 10053

oradebug event 10053 trace name context forever, level 1;

Por que isso é importante?

Você pode usar o 10046 pra pegar informações específicas de sql, tipo objeto, parsing, elapsed time, wait events, bind variables. É uma alternativa pro dbms_monitor e dbms_system, outro jeito de gerar um trace de sessão, e ele pode ser “tkprofado” também.

Se você quer entender as decisões do optimizer, não tem jeito melhor que usar um trace 10053. Você vai entender os cost estimates, access paths, query block names, peeked binds, parâmetros de optimizer usados durante o parse.

Em outro post eu vou dar detalhe sobre os levels, e por que a gente digita “name context forever”. Esse é um post how-to apenas =]

Falamos!