Kris Johnston's questions

Configurar:

Fazemos um backup incremental de nível 0 semanalmente usando:

RMAN> backup as compressed backupset incremental level 0 database;
RMAN> backup check logical as compressed backupset (archivelog all delete all input);

Fazemos um backup incremental de nível 1 todas as noites (exceto na noite em que fazemos o backup incremental de nível 0) usando:

RMAN> backup as compressed backupset incremental level 1 database;
RMAN> backup check logical as compressed backupset (archivelog all delete all input);

No RMAN, sei que posso informar quando a recuperação será iniciada e qual SCN precisará ser restaurado para limpar a imprecisão do arquivo de dados para trazer o banco de dados para um estado consistente usando o seguinte:

RMAN> restore database preview;

Media recovery start SCN is 49928711194
Recovery must be done beyond SCN 49928711196 to clear datafile fuzziness

Isso me diz que, se eu emitir um restore database;, precisarei recuperar o SCN 49928711194 para 49928711196 antes de poder abrir o banco de dados.

A partir daqui, sei que posso consultar quais backups de archivelog estão disponíveis e quais SCNs esses backups de archivelog contêm usando:

SELECT sequence#, first_change#, next_change#, id2, handle from (
  SELECT sequence#, first_change#, next_change#, id2
    FROM v$backup_archivelog_details where 49928711194 between first_change# and next_change#
UNION
  SELECT sequence#, first_change#, next_change#, id2
    FROM v$backup_archivelog_details where 49928711196 between first_change# and next_change#) archivelog
  JOIN v$backup_piece p
    ON archivelog.id2=p.set_count;

SEQUENCE#   FIRST_CHANGE#   NEXT_CHANGE#    ID2     HANDLE
22030       49923438913     49928711521     7940    L:\ORACLE\BACKUPS\ARCH_2_7940_1

Minha pergunta é: existe uma maneira de consultar uma v$exibição ou rcexibição para obter o SCN inicial e além do SCN que RMAN> restore database preview;fornece para limpar a imprecisão do arquivo de dados para um determinado conjunto de backup?

Temos um data warehouse Oracle Database com uma média de 120 confirmações por segundo (de acordo com o AWR). A principal atividade de espera é a sincronização do arquivo de log, o que é esperado... Por enquanto, os tempos de resposta gerais são satisfatórios, no entanto, estamos preocupados com a escalabilidade daqui para frente.

Infelizmente, devido à natureza da grande maioria dessas transações, a correção usual de "alterar seu aplicativo para confirmar com menos frequência" não é uma opção.

Estamos pensando seriamente em mudar esses commits para commits em lote assíncronos via:COMMIT WRITE BATCH NOWAIT;

Certamente estamos cientes de que isso seria quebrar o "D" no ACID, ou seja, que as transações confirmadas poderiam ser perdidas no caso de uma falha na instância. No entanto, a maioria dos commits mencionados acima são informações de registro em que, se perdermos uma transação aqui e ali devido a uma falha na instância, as consequências dessas transações perdidas são mínimas.

Eu entendo que com commits nowait em lote, os commits são armazenados em buffer no buffer de log (que podemos ajustar por meio do parâmetro init log_buffer, se necessário). No entanto, não consigo encontrar respostas para as seguintes perguntas:

1) Os commits em lote abrangem várias conexões? Em outras palavras, se nós:

 open a connection
 do work 
 commit write batch nowait;
 close the connection
 open another connection
 do work
 commit write batch nowait;
 close the connection 
 rinse, repeat...

Ambos os commits são em lote ou o Oracle libera os commits no disco para cada conexão quando a conexão é fechada?

2) Existe alguma maneira de descobrir com que frequência os commits em lote são gravados no disco e se tornam "duráveis"?

3) Os commits em lote gravados no disco são serializados? Em outras palavras: se o lote do aplicativo confirma o trabalho "A", o lote confirma o trabalho "B", o trabalho "A" é sempre gravado no disco antes do trabalho "B" ou é possível que o trabalho "B" seja gravado no disco antes que o trabalho "A" seja gravado no disco, a instância falha , o trabalho "A" é perdido, mas o trabalho "B" é durável?

Banco de dados primário: 11.2.0.3 Enterprise
Standby DB: 12.1.0.2 Enterprise

Encontrei vários artigos sobre como fazer alterações em um banco de dados de espera física, mas tenho tido dificuldade em localizar como habilitar o teste do usuário em um banco de dados de espera lógico transitório (em seguida, atualizar suas alterações e reativar o transporte de log e o SQL Apply após o teste foi concluído).

Com base no que sei sobre bancos de dados lógicos em espera, escrevi os seguintes procedimentos. No entanto, isso não foi testado, pois se eu estragar o Standby DB, não posso simplesmente reduplicar o banco de dados por meio do RMAN, pois as versões do banco de dados são diferentes. Terei essencialmente que clonar novamente o BD Primário, reconfigurar o Standby para dataguard, atualizar a versão do BD Standby, etc, etc... basicamente, muito trabalho que prefiro evitar, se possível...

Se alguém que já teve experiência com isso puder examinar meus procedimentos abaixo e me informar se estou esquecendo alguma coisa ou quais possíveis problemas / advertências devo observar ou estar ciente, eu agradeceria muito:

*nota: o transporte de log principal => standby é especificado em log_archive_dest_3

PRIMARY
alter system set log_archive_dest_state_3=defer scope=both;

STANDBY
alter database stop logical standby apply;
alter database guard none;
alter database flashback on;
create restore point before_testing guarantee flashback database;

*AFTER TESTING IS DONE*

STANDBY
flashback database to restore point 'before_testing';
drop restore point before_testing;
alter database flashback off;
alter database guard all;
alter database start logical standby apply immediate;

PRIMARY
alter system set log_archive_dest_state_3=enable scope=both;

Oracle Enterprise 11.2.0.3

estou recebendo:

ORA-31603: object "string of type "string" not found in schema "string"

ao executar uma função que chama dbms_metadata.get_ddl.

Eu sei que procedimentos/funções precisam ter as permissões concedidas explicitamente em vez de por meio de uma função: https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1065832643319

Também sei que as permissões necessárias para executar dbms_metadata.get_ddl estão na função SELECT_CATALOG_ROLE: https://sshailesh.wordpress.com/2010/05/08/dbms_metadata-get_ddl-avoid-ora-31603-error-by-using- select_catalog_role/

No entanto, a função SELECT_CATALOG_ROLE contém mais de 2.400 permissões. Então, quais são as permissões explícitas necessárias para executar dbms_metadata.get_ddl para que eu possa chamá-lo de uma função?

Caso de teste:

create or replace function getddl (p_type varchar2, p_object varchar2, p_owner varchar2)
return varchar2 as
begin
  return dbms_metadata.get_ddl(p_type, p_object, p_owner);
end getddl;

create table utilities.mytable (mycol varchar2(1));

select dbms_metadata.get_ddl('TABLE', 'MYTABLE', 'UTILITIES') from dual;
<DDL>

select getddl('TABLE', 'MYTABLE', 'UTILITIES') from dual;
ORA-31603: object "MYTABLE" of type TABLE not found in schema "UTILITIES"

EDITAR

Até agora, concedi explicitamente o seguinte ao usuário que possui getddl():

select any table
select any dictionary

Versão do banco de dados de origem: 11.2.0.3
Versão do banco de dados de destino: 12.1.0.2

Estou tentando importar todos os links de banco de dados de um banco de dados para outro usando dbms_datapump. O código está sendo executado no banco de dados de destino acima e puxando os links de banco de dados do banco de dados de origem acima por meio de um link de banco de dados.

Eu usei dbms_datapump.metadata_filter no passado para importar apenas determinados objetos (como funções ou procedimentos). No entanto, o seguinte retorna ORA-39001: valor de argumento inválido:

dbms_datapump.metadata_filter(h1,'INCLUDE_PATH_EXPR','IN (''DATABASE LINK'')');

Portanto, tentei a versão plural que também retornou ORA-39001:

dbms_datapump.metadata_filter(h1,'INCLUDE_PATH_EXPR','IN (''DATABASE LINKS'')');

Sei que devo estar perdendo algo básico aqui, mas pesquisar sobre esse problema tem sido irritante, pois os resultados da pesquisa com "dbms_datapump" e "link de banco de dados" na mesma pesquisa retornaram apenas resultados com como importar por um link de banco de dados, e não como para importar os links do banco de dados diretamente.

Eu costumava importar os links do banco de dados diretamente usando:

select DBMS_LOB.SUBSTR@dblinkimp(DBMS_METADATA.GET_DDL@dblinkimp
('DB_LINK', '[DBlinkName]', '[SchemaName]')) from dual@dblinkimp;

Em seguida, executaria a saída da instrução acima usando execute imediato, mas essa não é mais uma opção válida a partir de 11.2.0.4 (consulte Metalink Doc ID 1905221.1).