OCI :: How-To Clone Autonomous Database

Os autores desse artigo são:
Alexandre Fagundes - LinkedIn
Leandro Tocachelis - LinkedIn

Objetivo: 

Demonstrar os métodos possíveis de clonagem de dados e metadados de um banco autônomo residente no OCI. 

 

Considerações:

Uma das diversas funcionalidades do serviço de banco de dados autônomo do OCI (Autonomous Database), consiste na criação de clones de forma automatizada, obviamente, a partir de outro banco de dados autônomo já existente, e que resida na mesma região, bem como abaixo do mesmo tenant. O banco origem mantêm-se online durante todo o procedimento, ou seja, não há qualquer indisponibilidade.

Existem duas opções de clonagem: FULL e METADATA

FULL: Cria uma cópia fiel dos dados e metadados do banco. O tamanho de storage mínimo utilizado pela nova instância, deverá ser o mesmo ou pouco maior que o tamanho da origem. As estatísticas do otimizador de buscas do Oracle também são disponibilizadas, de acordo com os metadados populados pelas coletas de estatísticas, realizadas previamente no banco origem.

METADATA: Cria uma cópia apenas dos metadados do banco, sem os dados. O tamanho mínimo não necessariamente precisa ser idêntco ou maior ao da origem. As estatísticas do otimizador de buscas do Oracle são atualizadas automaticamente logo após carregamento de dados nas tabelas.


Procedimentos:

No console do OCI, posicione-se no menu de administração dos bancos Autônomos:

 Escolha o banco que está prestes a ser clonado. Na página de informações deste banco, clique em Actions e escolha a opção "Create Clone", conforme segue:

Outra opção viável para clonagem, seria através de qualquer backup que esteja disponível. Neste caso, o clone terá os dados presentes na origem até o momento em que o backup foi realizado. Basta posicionar-se na tela de gerenciamento do banco, ir até os backups e escolher a opção de "Create Clone", conforme segue:

Na tela a seguir, deverão ser escolhidas algumas opções de configuração do banco clone. Informações como compartment, o tipo do clone, nome, entre outras. No caso de ter sido iniciada a clonagem a partir de um backup, também será solicitado confirmação de qual está sendo utilizado.

A continuação das configurações agora irá questionar o shape do banco em questão, solicitando informações com número de OCPUs, quantidade de storage e necessidade ou não de Auto Scaling. Também é neste momento que deve-se informar a senha de administração:

Logo após informar as senhas, será solicitada a opção de licenças a serem utilizadas:

Todas as informações solicitadas preenchidas, basta clicar em "Create Autonomous Database" para iniciar o provisionamento. É importante ressaltar que o tempo deste provisionamento está relacionado ao tamanho da base de dados. Obviamente, quanto maior a base, mais tempo será necessário.

Banco de dados clonado com sucesso, e disponível para acesso.

Esperamos que este passo-a-passo contribua positivamente para disseminação de conhecimento, bem como para ilustração das automatizações já disponíveis, em ambientes residentes no OCI.


Obrigado!


REFERÊNCIAS:

https://docs.cloud.oracle.com/iaas/Content/Database/Concepts/adboverview.htm

https://youtu.be/86hPk5Lsk2s?list=PLgvLoiAxJHJ3WTdl7OEPwFXWV4h5YH9Go

https://youtu.be/An50s6-aMWE?list=PLgvLoiAxJHJ3WTdl7OEPwFXWV4h5YH9Go

OCI :: Create Autonomous Database

Os autores desse artigo são:

Leandro Tocachelis - LinkedIn
Alexandre Fagundes - LinkedIn

Objetivo: 

Demonstrar de forma sucinta os passos para criação e utilização de um banco de dados autônomo no OCI

Conceitos:

O serviço de Banco de Dados Autônomo do OCI consiste em um ambiente de banco de dados pré-configurado, somente em servidores Exadata, e totalmente auto-gerenciado, com dois tipos de carga de trabalho disponíveis: OnLine Transaction Processing (ATP) e Data Warehouse (ADW).

Não há necessidade alguma de configurar ou gerenciar nenhum hardware, ou instalar nenhum software. Após o provisionamento, é possível dimensionar o número de CPU cores, ou o tamanho de storage do banco de dados a qualquer momento, sem causar qualquer indisponibilidade ou degradar o desempenho.

O RDBMS Autônomo é responsável pela criação do banco de dados, bem como das seguintes tarefas de manutenção:

• Backup
  
• Patch
  
• Upgrade
  
• Tuning
  

Há 2 tipos de infra-estrutura disponíveis:

Infra-estrutura dedicada: Neste cenário, pode ser utilizado um hardware de Exadata exclusivo para seu banco autônomo. É possivel criar varios bancos autonomos, usando a mesma infra-estrutura dedicada.

Os dois tipos de carga de trabalho (ATP e ADW) podem ser provisionados com a infraestrutura dedicada do Exadata.

Infra-estrutura compartilhada: Nesta opção, é provisionado a instância do banco de dados autônomo em um Exadata compartilhado, mas completamente isolado de outros tenants, nao sendo possivel escolher especificamente qual hardware o banco irá residir.

Os dois tipos de carga de trabalho (ATP e ADW) podem ser provisionados com a infraestrutura compartilhada do Exadata.

Procedimentos para criação de uma nova instância:

Acessar a console > Abrir o menu do lado superior esquerdo > Ir para a seção Database > Escolher a opção desejada (ATP ou ADW) > Clicar em "Create Autonomous Database"

Preencher as informações solicitadas na tela.
Atentar para a opção Workload Type, pois não é possivel mudar após a criação do banco.

Prosseguir com o preenchimento das informações solicitadas.

Definir e preencher a senha do usuário ADMIN, que será utilizada para a conexão com o banco.

Após preencher as informações, clicar no Create Autonomous Database

O banco será provisionado em apenas alguns minutos.

Autonomous Database disponível.

Após a criação do banco, é possivel ter uma visualização em tempo real da carga de trabalho e desempenho do mesmo, atraves dos menus abaixo:

Service Console

Performance HUB

Tambem é possivel escalar a quantidade de OCPU e Storage disponivel para o banco, atraves do menu abaixo:

Scale Up/Down

Como podemos notar, atividades como criação, administração entre outras, sao extremamente simplificadas pela utilização das funcionalidades padrao da OCI.

REFERÊNCIAS:

https://docs.cloud.oracle.com/iaas/Content/Database/Concepts/adboverview.htm

https://youtu.be/86hPk5Lsk2s?list=PLgvLoiAxJHJ3WTdl7OEPwFXWV4h5YH9Go

https://youtu.be/An50s6-aMWE?list=PLgvLoiAxJHJ3WTdl7OEPwFXWV4h5YH9Go

VM Compute Instances com 2 VNICs

Os autores desse artigo são:
Leandro Tocachelis - LinkedIn
Alexandre Fagundes - LinkedIn

Objetivo: 

Dispor de um passo a passo estruturado para adicionar uma segunda placa de rede virtual, em uma compute instance do tipo VM no OCI.

 

Dicas e Considerações:

A premissa para necessidade de uma segunda placa de rede em uma VM, parte a princípio da falta de conectividade. Imagine uma situação, onde o seu fornecedor, cujo firewall bloqueia determinados CIDRs de rede, necessite acessar sua VM no OCI. A subnet desta VM coincide com um dos CIDRs bloquedos pelo firewall do fornecedor. Nestes casos, uma das possibilidades é a liberação de uma segunda placa de rede virtual, que obviamente pertença a outra subnet, que seja acessível para o fornecedor em questão.

Outraa situação trivial que pode exigir este tipo de configuração, seria a necessidade de a VM acessar outra VCN.

Por padrão, no OCI a segunda interface sempre permanecerá DOWN após reboot. Será necessário sempre subir a segunda interface para que se possa utilizá-la.

 

Procedimentos:

Para adicionar uma segunda VNIC, comece acessando as VNICs atachadas a VM instance, e clique em CREATE VNIC:

Preencha criteriosamente as informações solicitadas pelo console:

 

Validar a necessidade de ser aplicado algum NSG ou ainda,"Skip Source/Destination Check"

 

Valide também se será necessário atribuir um IP para sua VNIC, ou deixar que o OCI escolha o IP:

Abaixo pode-se verificar que a instance agora possui 2 VNICs, cada uma sob uma diferente subnet:

Imediatamente após criada, a VNIC já é atachada a instância, no entanto a interface permanece com status DOWN no S.O., e sem nenhuma definição de rota. A Oracle disponibiliza um script pronto, homologado, que quando executado atualiza a tabela de rotas, bem como sobe a interface deixando-a com status UP:

O script em questão, pode ser baixado do seguinte link:

https://raw.githubusercontent.com/oracle/terraform-examples/master/examples/oci/connect_vcns_using_multiple_vnics/scripts/secondary_vnic_all_configure.sh

 

Agora, basta tentar acessar os dois endereços e assegurar que ambos IPs conduzem a mesma instância: 

 

REFERÊNCIAS:

https://docs.cloud.oracle.com/iaas/Content/Network/Tasks/managingVNICs.htm#Linux:

https://raw.githubusercontent.com/oracle/terraform-examples/master/examples/oci/connect_vcns_using_multiple_vnics/scripts/secondary_vnic_all_configure.sh

Data-Refresh DB-System OCI

Os autores desse artigo sao:
Leandro Tocachelis - LinkedIn
Alexandre Fagundes - LinkedIn

Objetivo:

Viabilizar os passos para fazer um Data-Refresh de um DB-System no OCI, normalmente isso é feito em bancos de testes e/ou homologação.

Para quem trabalha na área, o Data-Refresh é uma atividade solicitada diversar vezes durante o ano e por varios motivos diferentes, pensando nisso decidimos criar esse artigo.

Sabemos que existem varias formas de fazer essas atividades, mas queremos demonstrar como isso é feito usando os recursos prontos que a OCI ja nos fornece.

Pré-requisitos *exclusivos* deste passo a passo:

Essa atividade exige que sejam cumpridos alguns pré-requisitos.
Se algum deles a resposta for negativa, o procedimento que deve fazer provavelmente é diferente desse artigo.

1. Data de atualização dos dados nao pode ser um valor exato (Ex: 23/12/2019 14h47min). Precisa ser em uma janela de tempo (Ex: entre 23/12/2019 14h00m e 23/12/2019 18h00m).
2. O backup a ser utilizado para criação do novo ambiente, deverá ser um backup automático (previamente configurado na console), ou entao um backup standalone (criado a partir da console dentro da janela de tempo).
3. Os DB-System's origem e destino devem residir no mesmo AD (obviamente na mesma regiao).
4. O DB-System destino deverá ser destruído antes do início do data-refresh

Dicas e Considerações:

Preferencialmente, os nomes dos PDBs residentes no DB-System origem, devem ser específicos, não utilizando o nome padrao que é dado na hora que eles foram criados (Ex: <SID>_PDB1).

• Esta ação pode evitar futuros equívocos. Ex: Strings de conexão, para o DB-System destino, com SERVICE_NAME idêntico ao da origem.

Previamente ao DB-System destino ser destruído, validar a necessidade de coletar algumas informações, como:

• DB-Links
• DBA Directories
• Usuários (DB e S.O)
• Agendamentos (jobs, crontab)
• Custom scripts 
• Backup de algum objeto/schema
• Backup Standalone do banco todo

Fortemente recomendado que as strings de conexões apontem para o HOSTNAME, tanto na origem como no destino. Pois, a cada novo DB-System criado a partir de um backup, é atribuído um novo IP automaticamente, mantendo apenas o HOSTNAME.

Procedimentos:

1. Coletar informações do DB-System antes de destruir:

   
   
   Alem dos detalhes do DB-System, verificar os outros itens que estao sugeridos na sessao "Dicas e Considerações" logo acima.

2. Destruir o DB-System que será recriado:

   

3. Verificar qual Backup será usado para criar o DB-System:

   Acessar o DB-System de origem e verificar quais os backups disponiveis.
   Verificar se algum deles se encaixa na janela de tempo que foi solicitado (Ex: entre 23/12/2019 14h00m e 23/12/2019 18h00m).
   
   

4. Iniciar a Criação do DB-System a partir do Backup:

   
   
   
   
   
   • O campo "Database Admin Password" é para colocar a nova senha do DB-System que esta sendo criado.
   • O campo "Password for Transparent Data Encryption (TDE) Waller or RMAN ENCRYPTON" é a senha do ambiente de origem para ser possivel restaurar o backup que estamos usando.
   
   Essas senhas podem e DEVEM ser diferentes.
   
   
    
   O tempo de provisionamento é correspondente ao tamanho do banco de dados.
   Quanto maior, mais tempo vai levar.
   Neste momento, apenas aguardar.

5. Confirmar a finalização da criação:

   
   
   
   
   
   
   Podemos observar que ficou com o mesmo nome do ambiente anterior que foi destruido.
   O IP esta outro, mas o HOSTNAME o mesmo, por isso a importancia de usar apenas o HOSTNAME em todas as strings de conexões.

6. Reconfigurar o novo DB-System de destino:

   Neste momento, esse novo DB-System esta com os dados iguais a producao, inclusive DB-Links, DIRECTORIES, UTL_FILE_DIR, Jobs, senha dos usuarios.
   
   Se antes de destruir foi feito algum backup de objeto/schema, esse é o momento para aplicar o backup, caso necessário.
   
   Verificar se algum desses itens precisa ser ajustado.
   

7. Liberar o ambiente para iniciar as atividades:

    Após terminar a reconfiguração do novo ambiente, o mesmo ja pode ser liberado para receber conexões das aplicações e/ou usuários.
   Se as strings estão usando o HOSTNAME, nao deve ocorrer nenhum erro de conexao no destino. Pois, a cada novo DB-System criado a partir de um backup, é atribuído um novo IP automaticamente, mantendo apenas o HOSTNAME.

Obrigado.