elfcheg's questions

Descobri recentemente que um dos nossos sistemas usa o banco de dados postgres padrão como... bem, banco de dados.

Quero mover todos os dados para outro db no mesmo cluster. Mas o banco de dados é relativamente grande e o sistema é um tanto 24/7.

Talvez eu pudesse simplesmente renomear o banco de dados postgres? E então criar outro chamado postgres e usá-lo como banco de dados de manutenção.

Isso parece algo inseguro de se fazer e minha intuição diz que devo continuar com os métodos tradicionais de despejo/restauração.

Ou talvez eu esteja exagerando?

devo definir

SQLNET.ALLOWED_LOGON_VERSION_SERVER=12a

em todos os meus servidores de banco de dados.

Como posso verificar se os clientes ainda usam protocolos de autenticação antigos?

Sei que posso verificar DBA_USERSversões antigas de senha. No entanto, como verificar se o usuário realmente usa a versão antiga da senha? listener.log? Trilha de auditoria?

Por favor sugira.

Digamos que eu queira implementar compactação básica para minha tabela. Eu sei que pode ser feito em duas etapas, por exemplo:

1. alterar tabela MYTABLE compactar;
2. alterar tabela MYTABLE mover;

Existe uma maneira de verificar se ambas as etapas foram implementadas? Como sei que os dados foram compactados?

Estou usando o Oracle 19c se isso importa.

Eu tenho um arquivo de dados em um estado de recuperação:

SQL> select status from v$datafile where file#=201;

STATUS
---------------------
RECOVER

Não tenho certeza de como foi danificado, parece que algo deu errado logo após o tempo de criação.

SQL> select creation_change#,creation_time,checkpoint_change#,checkpoint_time,last_change#,last_time
from v$datafile where file#=201;

CREATION_CHANGE# CREATION_TIME       CHECKPOINT_CHANGE# CHECKPOINT_TIME      LAST_CHANGE# LAST_TIME
---------------- ------------------- ------------------ ------------------- ------------- -------------------
    141311481693 29/08/2019 16:54:57       141311481694 29/08/2019 16:54:57  141311481738 29/08/2019 16:55:15

Eu verifiquei todas as tabelas em um tablespace ao qual este arquivo pertence e tudo parecia OK. Primeiro tentei SELECT /*+ FULL(t) */ count(*) from table_name;para todas as mesas, depois tentei ANALYZE TABLE table_name VALIDATE STRUCTURE;. Sem erros.

Tenho certeza de que não há opção para descartar um arquivo de dados offline/recuperar. Ou existe?

Eu tenho um pensamento em mente: crie um novo tablespace, mova todos os objetos para lá e então recrie o TS com um arquivo de dados com falha nele. Em seguida, mova tudo de volta. Isso é bom para fazer? Ou eu estou esquecendo de alguma coisa?

Conselho por favor.

Preciso fazer uma cópia do banco de dados de produção para desenvolvimento. Por algum motivo, não consigo usar o RMAN. Minha pergunta é: posso copiar o banco de dados standby enquanto ele estiver montado e a recuperação for cancelada? Claro que posso desligá-lo para fazer um "backup frio", mas não quero perder tempo copiando manualmente novos logs de arquivo (e não tenho espaço suficiente no primário para mantê-los por muito tempo).

O procedimento foi bom até hoje. Depois de algumas horas, consegui isso:

/usr/sfw/bin/gtar: owfin_d/owfin_d06.dbf: file changed as we read it.

É estranho porque os carimbos de data/hora em todos os arquivos db mostram a hora em que cancelei a recuperação em espera.

UPD Depois de muito tempo, encontrei o problema. Por algum motivo, um script no agendamento do cron altera as permissões do arquivo e o tar responde com "arquivo alterado conforme o lemos".