Nenhum resultado encontrado

Sua pesquisa não corresponde a nenhum resultado.

Sugerimos que você tente o seguinte para ajudar a encontrar o que procura:

  • Verifique a ortografia da sua pesquisa por palavra-chave.
  • Use sinônimos para a palavra-chave digitada; por exemplo, tente “aplicativo” em vez de “software.”
  • Tente uma das pesquisas populares mostradas abaixo.
  • Inicie uma nova pesquisa.
Perguntas Frequentes

Exadata: Migrando uma VM para outro DBServer

Revisado por Victor Ambrsut

Por Franky Weber Faust
Publicado em Setembro 2018

Objetivo: apresentar como migrar uma VM para outro Database Server (DBServer) do Exadata.

Atualmente trabalho com um Exadata X5-2 com Oracle VM e vez ou outra precisamos realizar uma manutenção específica para este ambiente, o qual é diferente de outras implementações de Exadata que vemos comumente por aí.

Num Exadata com Oracle VM temos nosso Database Servers um hypervisor que gerencia os Domains (VMs), sendo assim em cada DBServer podemos ter várias VMs para diferentes Databases. Esta é uma outra maneira de separar o workload dos Databases no Exadata.

Objetivo

Oracle Virtual Machine on Exadata

O objetivo é isolar o VM Domain exa-vm1 no DBServer exa-db1 no Exadata, para que este possa utilizar, quando necessário, todos os recursos disponíveis neste DBServer.

Processo de migração de VM no Exadata X5-2

Inicialmente vamos executar o utilitário "dcli" para poder acessar todos os DBServers do Exadata e listar as VMs:

[root@exa-db1 ~]# dcli -g all_dbnodes -l root "xm list" Processo de migração de VM no Exadata X5-2

O erro apresentado para conectar aos DBNodes exa-db7 e exa-db8 é devido ao isolamento da rede através de ACLs.

Neste exemplo como queremos isolar a VM exa-vm1 no exa-db1, então precisamos migrar a VM exa-vm3 para outro DBServer, neste caso vamos migrá-la para o exa-db6.

Para acessar a VM exa-vm3 podemos utilizar o comando "xm console exa-vm3.loredata.com.br" a partir do DBServer no qual ela está (exa-db1) ou diretamente via "ssh".

Como aqui estamos trabalhando no ambiente de contingência, para evitar indisponibilidades não necessárias para os Databases, vamos alterar a configuração do Standby para prepará-lo para a migração.

Efetuamos o acesso ao Broker:



[orclgt.oracle@exa-vm3 ~]$ dgmgrl sys/oracle@ORCLGT_DGMGRL

Listamos a configuração atual:

Listamos a configuração atual:

DGMGRL> show configuration Exadata

Agora alteramos o modo de proteção para Maximum Performance (Cuidado ao alterar isto no seu ambiente. Para saber mais leia este artigo):

DGMGRL> edit configuration set protection mode as maxperformance; Exadata

Também por precaução, mas não é necessário, podemos desabilitar a atualização do Standby (Redo Apply):

DGMGRL> edit database orclgt set state=apply-off; Exadata

Confirmamos que a alteração surtiu o efeito desejado:

DGMGRL> show database orclgt Exadata

Agora vamos efetuar o shutdown no banco de dados Standby:

[orclgt.oracle@exa-vm3 ~]$ srvctl stop database -d orclgt Exadata

Desabilitamos o startup automático (também não é necessário, pois o Clusterware salva o último status do recurso, vamos fazer só por garantia):

[orclgt.oracle@exa-vm3 ~]$ srvctl disable database -d orclgt Exadata

E então a partir do DBServer exa-db1 efetuamos o shutdown da VM exa-vm3:

[root@exa-db1 ~]# xm shutdown exa-vm3.loredata.com.br -w Exadata

Vamos conferir a lista das VMs online agora no DBServer exa-db1:

[root@exa-db1 ~]# xm list Exadata

Para realizar a migração precisamos copiar os arquivos da VM exa-vm3 para o DBServer exa-db6:



[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br  
root@exa-db6:/EXAVMIMAGES/GuestImages/


Exadata

Ainda no DBServer exa-db1 precisamos consultar o uuid da VM exa-vm3:

[root@exa-db1 ~]# grep ^uuid /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg Exadata

Vamos listar os arquivos da VM exa-vm3 no DBServer exa-db1 para ver se não esquecemos de algum que possa ser necessário:

[root@exa-db1 ~]# ls -lh /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/ Exadata

Vamos conferir o link simbólico para o arquivo de configuração da VM exa-vm3:

[root@exa-db1 ~]# ls -lh /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/ Exadata

Observe que o uuid da VM é o mesmo do diretório onde estão os link simbólicos.

Vamos listar também os links simbólicos dos discos da VM exa-vm3:

[root@exa-db1 ~]# ls -lh /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/ Exadata

Agora já no DBServer exa-db6 vamos criar o diretório dos links simbólicos dos discos e do arquivo de configuração da VM:

[root@exa-db6 ~]# mkdir -p /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks Exadata

Atenção a este passo apresentado acima, pois é citado de outra maneira na documentação e quando não foi feito este passo as interfaces InfiniBand não subiram na VM e consequentemente o Clusterware também não subiu devido a não conseguir acessar os discos dos Storage Cells.

Temos que criar também o link simbólico do arquivo de configuração:

[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/vm.cfg Exadata

Agora criamos os links simbólicos dos discos da VM:



[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/<nome_do_disco>.img 
/OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/ <uuid_do_disco>.img
Exadata

Vamos dar boot na VM exa-vm3 no DBServer exa-db6 utilizando o arquivo de configuração e já acessar a console através do parâmetro “-c" para acompanhar toda a inicialização da mesma:

[root@exa-db6 ~]# xm create /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg -c Exadata

Para sair do console da VM e voltar ao DBServer pressione "ctrl 5".

Listamos as VMs presentes no DBServer exa-db6:

[root@exa-db6 ~]# xm list Exadata

Podemos ver que a VM exa-vm3 está online no DBServer exa-db6 conforme nosso objetivo.

VM migrada e iniciada com sucesso no DBServer exa-db6.

Agora vamos habilitar o Standby Database novamente.

Habilitamos o startup do Database:

[orclgt.oracle@exa-vm3 ~]$ srvctl enable database -d orclgt Exadata

Efetuamos o startup:

[orclgt.oracle@exa-vm3 ~]$ srvctl start database -d orclgt Exadata

Acessamos o Broker:

[orclgt.oracle@exa-vm3 ~]$ dgmgrl sys/oracle@ORCLGT_DGMGRL Exadata

Iniciamos a atualização (Redo Apply) do Standby:

DGMGRL> edit database orclgt set state=apply-on; Exadata

Conferimos a alteração e de quanto tempo é o Gap, caso exista:

DGMGRL> show database orclgt Exadata

Vamos voltar a configuração para Maximum Availability:

DGMGRL> edit Configuration set Protection Mode as MaxAvailability; Exadata

Confirmamos que está como desejado:

DGMGRL> show configuration; Exadata

Lembre-se de desabilitar qualquer rotina que remova os Archivelogs do Primary ao efetuar esse procedimento para evitar trabalho desnecessário de resolução de Redo Gap.

Referências

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

Franky Weber Faust atua como administrador de banco de dados Oracle e MySQL no PagSeguro, tem 26 anos, é graduado em Tecnologia em Bancos de Dados e iniciou sua carreira trabalhando num projeto internacional da Volkswagen com os bancos de dados DB2 da IBM, SQL Server da Microsoft e tambémcom o Oracle e desde o início direcionou seus estudos para as tecnologias Oracle. É especialista em tecnologias de Alta Disponibilidade como RAC, Dataguard e GoldenGate e compartilha seus conhecimentos no blog loredata.com.br. Possui as certificações OCE SQL, OCA 11g, OCP 12c, OCS RAC 12c e OCS Linux 6.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle