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?
Princípio KISS: Você tem o armazenamento que oferece o nível de disponibilidade necessário (ou seja, array de discos)? E você tem backups RMAN com um catálogo de recuperação (você precisa dele de qualquer maneira, para DUPLICATE), não é? Se sim e sim, minha versão é: nenhum arquivo de controle secundário, um membro por cada grupo de redo, pois não há arquivos de dados secundários (obviamente, mesmo para system01.dbf) ou nenhum archivelogs secundário.
Caso contrário, seu banco de dados estará fazendo desnecessariamente coisas que pertencem ao nível de armazenamento. Eu apenas deixaria as coisas de armazenamento no nível de armazenamento - o espelho é feito lá e é feito de forma eficaz. Ou, se você quiser um espelhamento entre sites, faça isso no nível ASM. O banco de dados está ocupado com o processamento relacionado ao banco de dados. O espelhamento de software no nível do banco de dados só faz sentido se você usar discos rígidos vazios.
A maioria das pessoas, de forma conservadora, prefere ter três arquivos de controle. Provavelmente, o suporte da Oracle também recomendaria que você usasse três.
Não apenas nunca me beneficiei de ter um segundo ou terceiro arquivo de controle; Não consigo pensar em um cenário em que a cópia secundária seria justificada (ou seja, fornece algum benefício pela falta de simplicidade). Corrupção lógica no arquivo de controle seria propagada para um segundo arquivo de controle, assim como no caso de espelhamento de hardware. A corrupção física não seria propagada em nenhum dos casos. Se o armazenamento falhar, você perderá refazer ou dados - você precisará restaurar via RMAN de qualquer maneira. Você perde o arquivo de controle, pode restaurá-lo com RESTORE CONTROLFILE, que custa apenas um minuto extra no máximo. Se você perdeu o redo, a recuperação está incompleta. Se você não perdeu o redo (mas perdeu todos os arquivos de controle), a recuperação está completa de fato , mas a Oracle insiste em OPEN RESETLOGS (menos perda nesse caso).
Apenas certifique-se de que o backup automático do arquivo de controle esteja ativado. Se você adicionou ou descartou um arquivo de dados antes do backup do arquivo de controle, e você teve uma falha de hardware que resultou no CF único não acessível, seria uma dor de cabeça restaurar... não impossível, apenas uma grande dor de cabeça e uma perda de tempo durante um período delicado de retomada dos serviços.
Abraços, J. D.
Considerando tudo, não vejo razão para não ter mais arquivos de controle em (qualquer geração de) ODA.
Embora você nunca precise das cópias adicionais, é improvável que elas causem algum dano, e o tempo gasto é compensado por não precisar alterar nenhum hábito, documento ou processo - ou ter que mexer nas políticas do OEM para aceitar apenas um arquivo de controle.
Como o software OAK versão 12.x ODA usa ACFS, o que requer alguma consideração extra ao criar os arquivos de controle multiplexados, felizmente David Hueber publicou uma postagem explicando o processo, disponível em seu blog