Eu tenho um banco de dados Oracle 19.3 Multitenant que estou tentando aplicar a atualização de versão 19.7. O RU foi instalado pelo opatch muito bem. Mas o datapatch incorrerá no erro ORA-1114. Recebo erros como o seguinte em um dos logs:

SQL> alterar banco de dados conectável GOLD2020_06_18_123653 abrir instâncias de leitura e gravação=todos;
alterar o banco de dados conectável GOLD2020_06_18_123653 abrir instâncias de leitura e gravação =todas
*
ERRO na linha 1:
ORA-65107:Erro encontrado ao processar a tarefa atual na instância:1
ORA-17500:erro ODM:argumento inválido
ORA-01114:Erro de E/S ao gravar bloco no arquivo 12346 (bloco nº 1)
ORA-17500:erro ODM:argumento inválido
ORA-01114:Erro de E/S ao gravar bloco no arquivo 12345 (bloco nº 1)
ORA-17500:erro ODM:argumento inválido

Antes que eu possa explicar qual é o problema, deixe-me discutir como usamos o Multitenant em meu ambiente. Uma vez por semana, temos um cron job que cria uma cópia do nosso banco de dados de produção (usando instantâneos de hardware baseados em disco). Chamamos essa cópia de produção de nossa “imagem de ouro”. Esta imagem dourada está conectada ao nosso banco de dados como um de nossos PDBs. O nome do PDB está no formato GOLDaaaa_mm_dd_hhmiss para que saibamos quando esse PDB foi criado.

Todos os nossos bancos de dados de desenvolvimento e teste são criados a partir desse PDB de imagem dourada. Quando preciso atualizar DEV1 ou TEST, simplesmente desligamos o PDB para DEV1 ou TEST e o descartamos. Em seguida, criamos um clone instantâneo da última imagem dourada. O PDB da imagem dourada está no modo READ ONLY para facilitar o clone do snapshot.

Como escrevi aqui, quando um PDB é usado como fonte para um clone de snapshot, o Oracle altera as permissões do arquivo para 220. Este é o Oracle nos protegendo de nós mesmos. Não deveríamos ter permissão para modificar a origem de um clone de instantâneo para que o Oracle torne os arquivos de dados somente leitura. Quem na Oracle decidiu que mudar as permissões de arquivo era uma boa ideia não falou sobre isso com os desenvolvedores de datapatch.

O Datapatch vê o PDB READ ONLY e deseja abri-lo como READ WRITE, corrigir o interior do PDB e, em seguida, voltar para READ ONLY. No entanto, o datapatch não pode abrir o PDB no modo de leitura e gravação porque as permissões do arquivo não permitem. Daí os erros que estou recebendo.

A Oracle fez isso comigo ... eles forçaram as permissões de arquivo de uma maneira e, em seguida, o datapatch não pode fazer o que eles querem agora.

Ainda não recebi uma palavra oficial com minha solicitação de serviço, mas espero que isso se torne um bug. O Datapatch deve ignorar todos os PDBs que são fontes para clones de instantâneos, na minha opinião.

Enquanto isso, você pode forçar o seu caminho através disso. Tentei usar o parâmetro -exclude_pdbs para datapatch mas não funcionou. Aparentemente, há um bug conhecido em que esse parâmetro não funciona se sua lista de PDBs tiver uma vírgula. Então eu tive que executar o datapatch da seguinte forma:\

./datapatch -verbose -pdbs cdb\$root
./datapatch -verbose -pdbs pdb\$seed
./datapatch -verbose -pdbs dev1,dev2

Primeiro, executei o datapatch para corrigir o CDB$ROOT. Então eu corrigi PDB$SEED. Então eu corrigi meus PDBs dev. Eu simplesmente não corrigi meus PDBs de imagem dourada.