Roy's questions

Eu tenho um banco de dados Oracle 11gR2 RAC de produção com um standby físico de nó único. Agora chegou a hora de aposentar o antigo modo de espera e passar essa função para um RAC em hardware mais recente.

Não usamos Data Guard Broker.

Não consegui encontrar muito sobre esse processo em particular, então imaginei que talvez não houvesse tanto assim. Aparentemente, há pelo menos um pouco mais do que eu consegui pensar.

Depois de interromper a aplicação de log no modo de espera antigo, tentei simplesmente limpar o destino do log de espera e definir um novo destino para envio de log. A Oracle então reclama que o DB_UNQUE_NAME do novo standby físico não faz parte da configuração atual do Data Guard.

SQL> alter system set log_archive_dest_3='';

System altered.

SQL> alter system checkpoint;

System altered.

SQL> alter system set log_archive_dest_3='SERVICE=PDB10SBY LGWR ASYNC REGISTER VALID_FOR=(online_logfile,primary_role) REOPEN=60 DB_UNIQUE_NAME=PDB11SBY' scope=both sid='*';
alter system set log_archive_dest_3='SERVICE=PDB10SBY LGWR ASYNC REGISTER VALID_FOR=(online_logfile,primary_role) REOPEN=60 DB_UNIQUE_NAME=PDB10SBY' scope=both sid='*'
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-16053: DB_UNIQUE_NAME PDB10SBY is not in the Data Guard Configuration

Uma consulta rápida para v$dataguard_config confirma que existe uma configuração ativa contendo o DB_UNIQUE_NAME do antigo banco de dados standby.

SQL> select * from
  2  v$dataguard_config;

DB_UNIQUE_NAME
------------------------------
PDB10
PDB10_STBY

Então, a pergunta é: quais são as etapas necessárias para retirar uma configuração existente do Data Guard para que um novo banco de dados de espera físico possa ser implantado?

Em um banco de dados, o backup sugerido pela Oracle agendado no Enterprise Manager sempre termina na área de recuperação, apesar da configuração do RMAN mostrar que o formato de disco do tipo de dispositivo aponta para outro lugar.

Tanto quanto posso ver, o trabalho de backup agendado é simplesmente:

run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA_OEM_LEVEL_0';
backup incremental level 1 cumulative  copies=1 for recover of copy with tag 'ORA_OEM_LEVEL_0' database;
}

Pedir ao RMAN para show allrevelar que o disco do tipo de dispositivo está realmente configurado para armazenar em outro lugar:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/s01/backup/PROD11/PROD11_%U';

Se eu executar o script manualmente, o conjunto de backup é colocado no local acima, quando o script é executado no agendador de tarefas, o conjunto de backup vai para o grupo RECO no ASM,

Por que a Oracle ainda pode optar por despejar o conjunto de backup no db_recovery_file_dest?

Por fim, como posso alterar o destino do backup?

Ontem à noite, a área de recuperação em um de nossos Oracle Database Appliances ficou cheia. Isso foi relatado em um dos logs de alerta do banco de dados e conseguimos liberar algum espaço antes da próxima troca de log, ponto em que a produção teria sido interrompida.

Certamente teria sido bom ter um pouco mais de aviso, como quando o grupo de discos estava 70% cheio.

Quais opções temos para monitorar o uso do disco dentro do ASM?

Estou participando do curso gratuito de DB em Stanford Online e, francamente, um dos exercícios me deu alguns problemas. Tenho a sensação de que isso deve ser terrivelmente simples; portanto, para um DBA, obviamente não sou muito bom com SQL.

Estamos trabalhando com um cenário simplificado para classificar filmes.

Para todos os casos em que o mesmo crítico avaliou o mesmo filme duas vezes e deu a ele uma classificação mais alta na segunda vez, retorne o nome do crítico e o título do filme.

Aqui está o esquema:

Movie ( mID, title, year, director ) 
Reviewer ( rID, name ) 
Rating ( rID, mID, stars, ratingDate ) 

Como devo proceder?

As melhores práticas para o Oracle 11gR2 Data Guard implicam que os bancos de dados principal e standby devem ter o mesmo layout, por exemplo. RAC para RAC.

Quais considerações especiais seriam necessárias para replicar um banco de dados RAC para um standby físico de nó único?

Alguma razão pela qual isso seria uma péssima ideia?

Estou procurando garantir que todas as consultas em um aplicativo da Web php tenham o uso adequado de variáveis ​​de ligação para minimizar a análise das consultas.

Estou me perguntando como o Oracle analisa as consultas que comparam uma coluna a uma lista de valores. O Oracle considerará essas instruções iguais ou a lista deve estar dentro de variáveis ​​vinculadas?

select char from alphabet where char not in ('a', 'b');

select char from alphabet where char not in ('c', 'd');

Se o conteúdo da lista deve estar em uma variável de ligação, isso pode ser feito com uma única variável ou deve-se colocar cada item da lista em uma variável separada?

select char from alphabet where char not in (:list);

select char from alphabet where char not in (:c1, :c2);

Se o último for verdadeiro, as consultas com um número diferente de itens na lista ainda serão consideradas como tendo a mesma estrutura?

select char from alphabet where char not in (:c1, :c2);

select char from alphabet where char not in (:c1, :c2, :c3);

No Oracle Database Appliance, a implantação padrão oferece apenas um único arquivo control file.

Eu acho isso um pouco intrigante. O único arquivo de controle causa uma violação de política no Enterprise Manager DB Console configurado automaticamente e a recomendação da Oracle ainda é, até onde eu sei, que você sempre deve ter pelo menos dois arquivos de controle em unidades e sistemas de arquivos separados. Pessoalmente, sempre tive três cópias, só para garantir.

O ODA é configurado com ASM e tem um bom bit de redundância de armazenamento usando unidades espelhadas triplas. É correto executar com um único arquivo de controle nesta configuração?

Adicionar um segundo arquivo de controle ao mesmo grupo de discos pode não fazer muito sentido, multiplexar os arquivos de controle para o grupo de discos SSD ou talvez as unidades do SO de cada nó faria mais sentido?

É viável definir uma retenção de desfazer muito alta, para permitir consultas de flashback várias semanas atrás no tempo?

Naturalmente, espaço suficiente deve estar disponível nos tablespaces de undo para conter a quantidade de dados de undo necessários. Existem outras limitações das quais devo estar ciente?

O que acontece se não houver espaço suficiente para desfazer disponível? A produção será afetada de alguma forma, ou é apenas uma questão de flashback e reversão sendo limitada (instantâneo muito antigo etc).

Atualizar:

Com uma geração de desfazer típica de pouco menos de 1 GB por dia por instância e até 64 GB de espaço de desfazer por instância, parece viável executar com uma meta de retenção de desfazer de 30 dias. Não?

Estamos nos aproximando do final de 2012 e ainda me vejo contando com exportações de banco de dados para manter a capacidade de fazer operações de restauração em nível de linha. Embora este seja um método comprovado, com certeza seria bom se livrar de todas as operações de exportação que monopolizam os recursos do banco de dados por um número significativo de horas por dia.

Um cenário típico seria um cliente excluir acidentalmente um projeto ou documento de um sistema de autoria. Para corrigir isso, precisarei localizar e colocar de volta essas linhas excluídas.

Vou extrair um despejo de banco de dados do esquema do cliente de uma data anterior à exclusão acidental e importar os dados para um novo esquema. Agora posso identificar os dados perdidos e selecioná-los de volta no esquema de produção.

Eu sei que você pode fazer isso diretamente com a recuperação flash, mas há um limite para a quantidade de dados que podemos manter na área de recuperação rápida, e os clientes nem sempre descobrem seus erros dentro do tempo alocado.

Existe uma boa maneira de realizar esses tipos de tarefas com o uso do Oracle RMAN?

Desejo adicionar um segundo destino de log de arquivo a um banco de dados Oracle 11gR2 RAC com ASM, a ideia é que terei alguma redundância se o armazenamento primário falhar.

O log de arquivamento já está ativado e os logs estão atualmente arquivados na Fast Recovery Area. No entanto, até onde posso ver, nenhum dos parâmetros init LOG_ARCHIVE_DEST_n foi configurado.

Existe agora um padrão não definido que especifica a Fast Recovery Area como um destino de log?

Se for esse o caso, suponho que agora devo configurar dois destinos. Uma entrada para continuar gravando o arquivo nesse destino padrão e uma entrada para o destino de backup adicional. Em caso afirmativo, como especificar o local padrão existente na área de recuperação rápida?

Isso funcionará, existe outra maneira preferida?

alter system set log_archive_dest_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST';
alter system set log_archive_dest_2 = 'LOCATION=/s01/archive/TESTDB';
alter system set log_archive_dest_state_1 = enable;
alter system set log_archive_dest_state_2 = enable;
alter system set log_archive_min_succeed_dest = 1;

Naturalmente, o sistema de arquivos /s01 está disponível em todos (ambos) os nós do cluster.

Com a introdução dos Oracle Engineered Systems, o DBA está um pouco mais próximo das decisões de design de infraestrutura e espera-se que tenha pelo menos algumas opiniões sobre os requisitos de design de rede para o banco de dados. Pelo menos é essa a situação em que me encontro :)

Depois de implantar um ODA para teste, encontro-me com a configuração atual:

O controlador de sistema 0 tem a interface vinculada pública (bond0) conectada a um switch de borda típico, um Catalyst 2960 series. Uma interface de gerenciamento (bond1) é conectada a um segundo switch de borda do mesmo tipo.

Da mesma forma, o controlador do sistema 1 tem sua interface pública conectada ao segundo switch, enquanto a interface de gerenciamento está conectada ao primeiro switch.

Dessa forma, se um dos interruptores cair, um operador poderá acessar cada controlador do sistema por meio da interface pública ou de gerenciamento para facilitar o diagnóstico.

No lado da Cisco, os grupos EtherChannel são configurados para as 4 interfaces vinculadas do ODA. Os dois switches são conectados individualmente ao restante da rede, sem links diretos entre os dois.

À primeira vista, isso parece um design razoável, mas quanto mais penso em diferentes cenários de falha, mais perguntas parecem surgir.

Levando em consideração que esses switches do tipo edge não são redundantes em si mesmos, parece bastante importante que o cluster possa lidar com um switch que se torne indisponível devido a uma falha na fonte de alimentação ou um switch que não consiga encaminhar pacotes.

Os clientes do banco de dados (servidores de aplicativos do servidor Zend, neste caso) são conectados de forma semelhante com uma interface vinculada a apenas um dos dois switches. Isso levanta algumas questões em relação ao balanceamento de carga: Do jeito que eu entendo 11gR2 RAC, simplesmente conectar ao endereço SCAN provavelmente permitirá que o cliente percorra o longo caminho até a rede principal e volte por outro switch, o que dificilmente pode ser considerado para ser muito eficiente.

O que acontece se um switch falhar ou parar de encaminhar pacotes? As conexões encontrarão o ouvinte VIP acessível por meio do SCAN? O RAC detectará de alguma forma a falha na rede e moverá o SCAN e o VIP para o controlador do sistema com uma interface pública funcional e acessível? Sinceramente, não consigo ver como seria.

E embora os clientes que percorrem o caminho mais longo pela rede principal e voltem seja aceitável durante um cenário de failover, com certeza seria bom evitá-lo na produção normal.

Tenho certeza de que a Oracle tem uma ideia muito clara de como tudo isso deve funcionar junto, mas infelizmente não vejo tudo com tanta clareza.

É possível obter redundância total com switches edge-class/não redundantes? Podemos de alguma forma adicionar algum controle sobre onde as conexões do cliente são roteadas em situações de produção e failover? Talvez haja uma boa maneira de interconectar os dois switches para permitir o tráfego diretamente entre os clientes em um switch e o ouvinte do banco de dados no outro?

Neste ponto, estou procurando as melhores práticas e considerações fundamentais de design de rede que devem ser aplicadas a uma implementação típica de ODA de alta disponibilidade.

Esperançosamente, isso será útil para qualquer DBA que se depare com a tomada de decisões de design de rede para seu ODA :)

Atualizar:

O ODA é configurado com vínculos na configuração de backup ativo. Acho que isso pode permitir uma configuração em que cada interface no vínculo seja conectada a um comutador diferente, sem nenhuma configuração do lado do comutador.

Alguém sabe se é este o caso?

[root@oma1 ~]# cat /proc/net/bonding/bond0 
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth2

Após a implantação do Oracle Database Appliance com OAK 2.3.0, os ouvintes padrão são configurados para a rede pública em bond0. Isso inclui ouvintes SCAN e um ouvinte VIP por nó. Este último parece escutar tanto na interface de rede pública quanto na interface VIP.

No entanto, também gostaria de ouvir algo na rede de gerenciamento que configurei no bond1.

Qual seria a maneira preferida de fazer isso? Posso fazer com que o ouvinte VIP também ouça o bond1 ou devo adicionar um novo ouvinte para isso?

Posso apenas adicionar um ouvinte com: srvctl add listener -p TCP:1521 -o /u01/app/11.2.0.3/grid?

Não consigo ver onde o endereço IP ou a interface entra na configuração.

Atualização: a nota de suporte 1063571.1 "Como configurar um segundo ouvinte em uma rede separada na infraestrutura de grade 11.2" abrange a adição de um segundo ouvinte de produção com interfaces VIP associadas (mas nenhum segundo ouvinte SCAN) a um RAC 11gR2 genérico.

Nesse caso, como isso deve ser uma porta dos fundos para operadores e DBAs, acho que pode ser bom ter um ouvinte básico diretamente na interface física de cada nó - por exemplo. aquele que não falha e se conecta apenas às instâncias naquele nó específico.

Suponho que também pode haver considerações específicas de ODA que precisam ser levadas em conta, embora nenhuma seja muito clara para mim neste momento.

Existe uma maneira conveniente de importar um esquema para o Oracle 11gR2 usando um único tablespace novo ou diferente do local de origem dos dados?

Como exemplo, exportei BLOG_DATA do OLDDB, onde todos os dados do usuário são armazenados no tablespace USERS.

No NEWDB, gostaria de importar o esquema BLOG_DATA, mas armazenar os objetos de usuário no tablespace BLOG_DATA, criado especificamente para este usuário.

Criei o usuário BLOG_DATA, criei o tablespace BLOG_DATA e o defini como o tablespace padrão para esse usuário e adicionei uma cota ilimitada apropriada.

CREATE TABLESPACE blog_data DATAFILE SIZE 1G;

CREATE USER blog_data IDENTIFIED BY secretpassword DEFAULT TABLESPACE blog_data QUOTA UNLIMITED ON blog_data;

GRANT connect,resource TO blog_data

O esquema foi exportado do OLDDB com algo como

exp blog_data/secretpassword@OLDDB file=blog_data.dmp 

Depois de ler a excelente resposta de Phil abaixo, me perguntei :

Como os dados não têm outro lugar para ir além do tablespace padrão - o único tablespace no qual o usuário tem uma cota - isso forçará efetivamente o imp a colocar todos os objetos de usuário nesse tablespace padrão?

imp blog_data/secretpassword@NEWDB file=blog_data.dmp

Isso colocaria todo o esquema blog_data no tablespace blog_data em NEWDB? Existe alguma razão pela qual isso não funcionaria ou que eu teria problemas com certos objetos, etc?

atualizar:

Fiz um teste rápido e descobri que sim. Impcoloca objetos no tablespace padrão para aquele usuário, desde que não possa colocá-lo no tablespace original (por exemplo, o tablespace não existe). Explicação completa: http://www.dolicapax.org/?p=57

Ainda assim, suponho que usar o Data Pump como Phil sugere pode ser a opção preferida.