Re: [oracle_br] Re: Trigger de monitoramento de tran sação
Então Chiappa!!! Eu até tentei argumentar, mas k... É melhor deixar pra lá. Eu fiz um negócio bem simples aqui e mandei. Em 22 de fevereiro de 2017 19:12, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > cara, primeiro observo que para procedimento técnico não tem essa do > cliente "querer" : se ele tiver uma razão ** séria ** e tecnicamente válida > para a recusa ok, a gente escuta, mas se não não faz sentido ele palpitar > no que não sabe... Não é você o Consultor, que eles estão Pagando pelo > conhecimento técnico ?? Então No máximo, se eles insistirem, se municia > no asktom que vc acha artigos dizendo com todas as letras que via de regra > QUALQUER built-in do RDBMS é muito mais performático (por ser escrito em C > compilado ** e ** situado no kernel do banco , versus a sua coitada rotina > em PL/SQL interpretado E externa ao kernel), além de ser Muito mais ** > barato ** para implementar (eles não tiveram que pagar as ** várias ** > horas/homem de programação necessárias), E como complemento via de regra é > ** muito ** mais Estável (pois foi escrito por um TIME de desenvolvedores, > depois sujeito a code review, bem diferente do programador eu-sozinho que > acho ser o seu caso)... > APRESENTA esses argumentos pro teu cliente, que daí se por Teimosia, > burrice ou qquer razão não-técnica ele não os aceitar vc FEZ a sua > obrigação : mais tarde se neguim reclamar do custo, do tempo que levou pra > desenvolver ou da Estabilidade da solução customizada, vc tem aonde > apelar... > > Só digo de novo : > > 1. Não Deixe de validar as outras auditorias built-in além do comando > AUDIT, principalmente a possibilidade de log miner > > e > > 2. se for programar, não deixe de checar se a tua versão de banco > permite coisas como a trigger de DDL após AUDIT, para fazer Combinações > entre o nativo e o customizado > > e > > 3. se vc for precisar lançar mão da técnica de criar uma trigger de DML > pra cada tabela a Auditar, estude ** carinhosamente ** os links que te dei > > > []s > >Chiappa > >
Re: [oracle_br] Re: Trigger de monitoramento de tran sação
cara, primeiro observo que para procedimento técnico não tem essa do cliente "querer" : se ele tiver uma razão ** séria ** e tecnicamente válida para a recusa ok, a gente escuta, mas se não não faz sentido ele palpitar no que não sabe... Não é você o Consultor, que eles estão Pagando pelo conhecimento técnico ?? Então No máximo, se eles insistirem, se municia no asktom que vc acha artigos dizendo com todas as letras que via de regra QUALQUER built-in do RDBMS é muito mais performático (por ser escrito em C compilado ** e ** situado no kernel do banco , versus a sua coitada rotina em PL/SQL interpretado E externa ao kernel), além de ser Muito mais ** barato ** para implementar (eles não tiveram que pagar as ** várias ** horas/homem de programação necessárias), E como complemento via de regra é ** muito ** mais Estável (pois foi escrito por um TIME de desenvolvedores, depois sujeito a code review, bem diferente do programador eu-sozinho que acho ser o seu caso)... APRESENTA esses argumentos pro teu cliente, que daí se por Teimosia, burrice ou qquer razão não-técnica ele não os aceitar vc FEZ a sua obrigação : mais tarde se neguim reclamar do custo, do tempo que levou pra desenvolver ou da Estabilidade da solução customizada, vc tem aonde apelar... Só digo de novo : 1. Não Deixe de validar as outras auditorias built-in além do comando AUDIT, principalmente a possibilidade de log miner e 2. se for programar, não deixe de checar se a tua versão de banco permite coisas como a trigger de DDL após AUDIT, para fazer Combinações entre o nativo e o customizado e 3. se vc for precisar lançar mão da técnica de criar uma trigger de DML pra cada tabela a Auditar, estude ** carinhosamente ** os links que te dei []s Chiappa
Re: [oracle_br] Re: Trigger de monitoramento de transação
Fala Chiappa Foi sugerido o Audit Trail para o cliente, mas eles não quiseram. Estou tentando fazer alguma coisa aqui na unha, estou colocando em prática aquele curso de PL/SQL. k Obrigado. Att, Wanderson Em 22 de fevereiro de 2017 17:30, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Bom, antes de mais nada nós ** temos ** que te dizer que desde que vc não > esteja usando pool de conexão ou middlewares , via auditoria básica > (comandos AUDIT) vc obtém ** todos ** esses detalhes : o IP é com um AUDIT > CONNECT (vide https://asktom.oracle.com/pls/asktom/f?p=100:11:P11_ > QUESTION_ID:526822275627),e o resto das informações (ie,) a operação, > data, usuário, NOME DA MÁQUINA CLIENTE, etc), é com AUDIT comum, fica no > AUDIT TRAIL, veja a página sobre ele na documentação Oracle > > Apenas SE ** realmente ** vc não puder usar a Auditoria nativa (seja por > que motivo for) é que, aí sim, vc terá que escrever algo SEMPRE, > sempre, ** sempre *** essa opção de sair re-inventando a roda é ** RUIM ** > mas se chegar nisso, azar > > Se realmente chegar nisso, provavelmente vc vai ter uma trigger de > INSERT/UPDATE/DELETE pra cada tabela que vc quiser monitorar : OBVIAMENTE > vc não vai escrever cada trigger uma por uma manualmente, vc VAI as gerar > programaticamente tipo https://asktom.oracle.com/pls/ > asktom/f?p=100:11:P11_QUESTION_ID:59412348055... > > []s > >Chiappa > > OBS : > > 1. além da auditoria nativa via AUDIT, vc tem ** várias ** outras opções > de Auditoria sem ter que ficar programando no RDBMS Oracle, como por > exemplo LOG MINER : avalie elas > > e > > 2. no 11g vc tem a opção de ** complementar ** a auditoria nativa, tendo > uma trigger que dispara antes ou depois de comando AUDIT, cfrme > http://psoug.org/reference/ddl_trigger.html No 10g velhinho de > guerra (que é a sua versão se me lembro) iirc não existe essa opção, mas dá > uma confirmada nisso tambémmm > >
[oracle_br] Re: Trigger de monitoramento de transação
Bom, antes de mais nada nós ** temos ** que te dizer que desde que vc não esteja usando pool de conexão ou middlewares , via auditoria básica (comandos AUDIT) vc obtém ** todos ** esses detalhes : o IP é com um AUDIT CONNECT (vide https://asktom.oracle.com/pls/asktom/f?p=100:11:P11_QUESTION_ID:526822275627),e o resto das informações (ie,) a operação, data, usuário, NOME DA MÁQUINA CLIENTE, etc), é com AUDIT comum, fica no AUDIT TRAIL, veja a página sobre ele na documentação Oracle Apenas SE ** realmente ** vc não puder usar a Auditoria nativa (seja por que motivo for) é que, aí sim, vc terá que escrever algo SEMPRE, sempre, ** sempre *** essa opção de sair re-inventando a roda é ** RUIM ** mas se chegar nisso, azar Se realmente chegar nisso, provavelmente vc vai ter uma trigger de INSERT/UPDATE/DELETE pra cada tabela que vc quiser monitorar : OBVIAMENTE vc não vai escrever cada trigger uma por uma manualmente, vc VAI as gerar programaticamente tipo https://asktom.oracle.com/pls/asktom/f?p=100:11:P11_QUESTION_ID:59412348055... []s Chiappa OBS : 1. além da auditoria nativa via AUDIT, vc tem ** várias ** outras opções de Auditoria sem ter que ficar programando no RDBMS Oracle, como por exemplo LOG MINER : avalie elas e 2. no 11g vc tem a opção de ** complementar ** a auditoria nativa, tendo uma trigger que dispara antes ou depois de comando AUDIT, cfrme http://psoug.org/reference/ddl_trigger.html No 10g velhinho de guerra (que é a sua versão se me lembro) iirc não existe essa opção, mas dá uma confirmada nisso tambémmm
[oracle_br] Trigger de monitoramento de transação
Caros, Alguém tem algum script de trigger que monitora transações no banco de dados, por exemplo, eu quero saber quem fez insert, update ou delete nas tabelas, preciso saber também informações como nome do usuário, nome da tabela, o tipo de operação (insert, update, ou delete), date e hora, máquina, IP etc.. Obrigado. Att, Wanderson
[oracle_br] Re: Recuperar dados de uma tabela particionada
Basta vc indicar a ** partição ** que vc quer, além do nome da tabela no parâmetro TABLES do impdp, tipo : impdp usuario directory=diretorio . demais params tables=nomedatabela:nomedapartição []s Chiappa OBS : só não lembro se quando vc importa só a partição o datapump já cria a partição se ela não existir ou não, teste aí...
Re: RES: RES: RES: [oracle_br] Re: Recover database
"Uma ultima pergunta: então antes de começar o recover database, o RMAN verifica os archivelog que ele irá precisar, e como ele não encontra ele dá aquele erro?" Isso aí... "Saideira: o melhor para este caso seria fazer um recover database until sequence xxx; ou fazer um restore dos archivelog em disco e depois aplicar?" Depende do que vc precisa : se vc confirmou que tem sem faltar nenhum todos os archives que contém as sequences até xxx E é aceitável vc perder os dados das transações posteriores, que iniciaram após os logs archivados nesse arquive com essa sequence ok, vc pede um recover until sequence x e vai que vai Agora, se vc ** exige ** que o recover atualize o banco até o último últimíssimo SCN registrado nos seus archives vc pede um UNTIL CANCEL (ou equivalentes) e aí não tem jeito, para que esse recover "completíssimo" aconteça, se os archives não estão em disco E se o RMAN não conseguir localizar / restaurar sozinho os backups que os contém vc ** TEM ** que providenciar as sequences TODAS que ele pedir, não tem por onde... []s Chiappa
[oracle_br] Recuperar dados de uma tabela particionada
Pessoal, Como faço para restaurar os dados de uma partição via datapump? Tenho um export diário de minhas tablespace. Ex. Tabela: LIVRO_FISCAL, nela tenho a partição de 2010 Para não perder muito tempo acabei voltando a tabela toda em outro owner, mas queria saber como restaurar apenas os dados dessa partição. Oracle Database Enterprise 10g (release 10.2.0.5) Grato, Ednilson
RES: RES: RES: [oracle_br] Re: Recover database
Chiappa, Perfeito, entendido... Uma ultima pergunta: então antes de começar o recover database, o RMAN verifica os archivelog que ele irá precisar, e como ele não encontra ele dá aquele erro? Saideira: o melhor para este caso seria fazer um recover database until sequence xxx; ou fazer um restore dos archivelog em disco e depois aplicar? Grato, Ednilson De: sentto-1682896-121558-1487782614-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-121558-1487782614-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de jlchia...@yahoo.com.br [oracle_br] Enviada em: quarta-feira, 22 de fevereiro de 2017 13:57 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: [oracle_br] Re: Recover database Opa : sobre os backups, não conheço essa solução (StarOnce) então não posso dizer nada sobre integridade (em especial coisas se ela tem proteção contra, digamos, tentar backupear um archive no exato instante em que ele está ainda aberto e em uso pelo RDBMS Oracle) - eu sempre dou ** total ** preferência para backups via RMAN justamente por confiar mais que esse tupo de coisa nunca acontece, já que o RMAN ** reconhece ** os locks/proteções de arquivos impostos pelo RDBMS mas ok, por desconhecimento não posso comentar nada sobre ela, repito... Isso traz um outro ponto à baila : Obviamente, o RMAN só conhece os backups feitos por ele : se vc tá usando essa tal solução de terceiros (StarOnce), a menos que ela tenha alguma "ligação" com o RMAN via library/DLL/whatever, o RMAN *** não saberá NADICA DE NADA *** sobre ela, então o controle desses backups vc faz à parte , com as tools/ferramentas do fornecedor, necessariamente Sobre sua outra pergunta, o funcionamento do RDBMS e do RMAN é : o banco possui um número (uma SEQUENCE numérica, se vc quiser) constantemente crescendo a cada poucos segundos ** ou ** quando uma transação é startada (cada Transação sempre vai ter seu 'número' único), e esse "sequencial" se chama SCN, e ele é referenciado nos datafiles (quando as coisas que estão nos buffers são efetivadas no datafile fica registrado no cabeçalho dele o SCN corrente dessa ocasião, que pode ser rara, já que o RDBMS tenta gravar o mínimo possível nos datafiles e sempre lentamente, em background), no CONTROLFILE (indicando o SCN mais atual do sistema, digamos assim) e nos REDO LOG FILES (no formato LOW and HIGH, ie, um par indicando que aquele REDO LOG FILE tal possui logs que se referem à transações feitas desde o SCN x até o SCN y)... Mais tarde, quando o REDO LOG FILE é arquivado, ele ganha um SEQUENCE NUMBER, ie, um OUTRO número sequencial que serve para identificar unicamente aquele archive ==> OU SEJA : em tese, é perfeitamente possível que uma transação T1 comece e ganhe um SCN 1000 (e portanto teu REDO LOG FILE atual L1 tenha como LOW SCN 1000), aí SEM encerrar essa transação outras transações T2, T3, etc, comecem e passem a gerar montes de redo, que vão encher o logfile L1, depois o L2, depois o L3, etc, etc , que vão ser arquivados e gerar os archives com sequências (digamos) 5, 50001, 50002, etc, E ao mesmo tempo o SCN corrente vai avançando no controlfile e para fins didáticos suponha que os datafiles não sejam atualizados nesse intervalo e portanto continuem com SCN abaixo de 1000 Aí digamos que só então a nossa transação T1 volte a gerar redo no logfile atual L5 : como essa transação ** ainda ** tem como SCN 1000, necessariamente esse logfile vai ter 1000 como LOW SCN, e quando esse logfile for arquivado ele ganha digamos uma sequence de 50005, e que ela é comitada pouco depois... Neste cenário, se mais tarde vc tiver que recuperar e atualizar esse banco, justamente por causa dessa transação T1 que se "espalhou" por diferentes logfiles archivados em diferentes sequências vc vai precisar TANTO do archive com sequência 5 ** quanto ** do archive com sequência 50005 Esse tipo de coisa pode ** sim ** acontecer, e imho EXPLICAM adequadamente os casos em que vc é solicitado a localizar archives com sequences muito distantes entre si, em especial sequências muito "antigas" no tempo : normalmente as pessoas lembram que quando vc faz o backup o RMAN força um checkpoint (atualizando o SCN nos datafiles, okdoc) mas Não encerra as transações porventura acontecendo Assim, te respondendo : se vc pediu um RECOVER ** sem ** especificar o limite e ele tá pedindo por archives gerados ** depois ** do backup pra mim é isso, vc tinha alguma transação aberta no momento do HOT BACKUP (que tem esse nome Justamente porque o banco está ABERTO pra transações durante o backup) , que gerou redo log em logfiles posteriores ao término do backup de banco Finalmente : o fato de em um backup file/backup piece vc poder ter diferentes archives (cada um, óbvio, com diferentes sequences) sem uma ordenação definida, não tem problema algum - como foi dito, se os backup
Re: RES: RES: [oracle_br] Re: Recover database
Opa : sobre os backups, não conheço essa solução (StarOnce) então não posso dizer nada sobre integridade (em especial coisas se ela tem proteção contra, digamos, tentar backupear um archive no exato instante em que ele está ainda aberto e em uso pelo RDBMS Oracle) - eu sempre dou ** total ** preferência para backups via RMAN justamente por confiar mais que esse tupo de coisa nunca acontece, já que o RMAN ** reconhece ** os locks/proteções de arquivos impostos pelo RDBMS mas ok, por desconhecimento não posso comentar nada sobre ela, repito... Isso traz um outro ponto à baila : Obviamente, o RMAN só conhece os backups feitos por ele : se vc tá usando essa tal solução de terceiros (StarOnce), a menos que ela tenha alguma "ligação" com o RMAN via library/DLL/whatever, o RMAN *** não saberá NADICA DE NADA *** sobre ela, então o controle desses backups vc faz à parte , com as tools/ferramentas do fornecedor, necessariamente Sobre sua outra pergunta, o funcionamento do RDBMS e do RMAN é : o banco possui um número (uma SEQUENCE numérica, se vc quiser) constantemente crescendo a cada poucos segundos ** ou ** quando uma transação é startada (cada Transação sempre vai ter seu 'número' único), e esse "sequencial" se chama SCN, e ele é referenciado nos datafiles (quando as coisas que estão nos buffers são efetivadas no datafile fica registrado no cabeçalho dele o SCN corrente dessa ocasião, que pode ser rara, já que o RDBMS tenta gravar o mínimo possível nos datafiles e sempre lentamente, em background), no CONTROLFILE (indicando o SCN mais atual do sistema, digamos assim) e nos REDO LOG FILES (no formato LOW and HIGH, ie, um par indicando que aquele REDO LOG FILE tal possui logs que se referem à transações feitas desde o SCN x até o SCN y)... Mais tarde, quando o REDO LOG FILE é arquivado, ele ganha um SEQUENCE NUMBER, ie, um OUTRO número sequencial que serve para identificar unicamente aquele archive ==> OU SEJA : em tese, é perfeitamente possível que uma transação T1 comece e ganhe um SCN 1000 (e portanto teu REDO LOG FILE atual L1 tenha como LOW SCN 1000), aí SEM encerrar essa transação outras transações T2, T3, etc, comecem e passem a gerar montes de redo, que vão encher o logfile L1, depois o L2, depois o L3, etc, etc , que vão ser arquivados e gerar os archives com sequências (digamos) 5, 50001, 50002, etc, E ao mesmo tempo o SCN corrente vai avançando no controlfile e para fins didáticos suponha que os datafiles não sejam atualizados nesse intervalo e portanto continuem com SCN abaixo de 1000 Aí digamos que só então a nossa transação T1 volte a gerar redo no logfile atual L5 : como essa transação ** ainda ** tem como SCN 1000, necessariamente esse logfile vai ter 1000 como LOW SCN, e quando esse logfile for arquivado ele ganha digamos uma sequence de 50005, e que ela é comitada pouco depois... Neste cenário, se mais tarde vc tiver que recuperar e atualizar esse banco, justamente por causa dessa transação T1 que se "espalhou" por diferentes logfiles archivados em diferentes sequências vc vai precisar TANTO do archive com sequência 5 ** quanto ** do archive com sequência 50005 Esse tipo de coisa pode ** sim ** acontecer, e imho EXPLICAM adequadamente os casos em que vc é solicitado a localizar archives com sequences muito distantes entre si, em especial sequências muito "antigas" no tempo : normalmente as pessoas lembram que quando vc faz o backup o RMAN força um checkpoint (atualizando o SCN nos datafiles, okdoc) mas Não encerra as transações porventura acontecendo Assim, te respondendo : se vc pediu um RECOVER ** sem ** especificar o limite e ele tá pedindo por archives gerados ** depois ** do backup pra mim é isso, vc tinha alguma transação aberta no momento do HOT BACKUP (que tem esse nome Justamente porque o banco está ABERTO pra transações durante o backup) , que gerou redo log em logfiles posteriores ao término do backup de banco Finalmente : o fato de em um backup file/backup piece vc poder ter diferentes archives (cada um, óbvio, com diferentes sequences) sem uma ordenação definida, não tem problema algum - como foi dito, se os backup file/pieces todos estiverem catalogados no RMAN e fisicamente disponíveis na mídia de backup o RMAN é completamente capaz de localizar exatamente qual backup file/piece contém qual archive que ele precisa []s Chiappa
RES: RES: [oracle_br] Re: Recover database
Chiappa,
Verifiquei com o pessoal de backup e existe duas copias do backup. Primeiro é
feito em disco (StarOnce) que fica retido por 30 dias e depois é levado para
fita LTO.
Estamos verificando de criar uma terceira copia deste backup. Obrigado por este
dica.
Sobre minha pergunta de o RMAN esta pedindo archivelog que não tenho na fita,
acho que não fui claro.
Quando executo apenas o recover database, o RMAN pede arquivo mais recentes que
estão em outro backup depois desse meu full.
No meu log exemplo tenho a sequencia de archivelog de 334274 a 334625 e o RMAN
pede a sequencia 334626 em diante, não entendi porque ele faz isso.
Nos demais backup que tenho de outros bancos, isso não ocorre.
Usei o comando abaixo para listar meus achive, esse meu backup é incremental
level 0 com 32 canais e começa as 04:00 e termina por volta das 9:00
list backup of archivelog time between "to_date('17/02/2017
04:00:00','DD/MM/ HH24:MI:SS')" and "to_date('17/02/2017
09:00:00','DD/MM/ HH24:MI:SS')";
Uma pergunta (desculpe se for ignorante), no log e listando com esse comando as
sequencias estão fora de ordem, isso por ser um problema para fazer o recover?
Exemplo, fez backup das sequencias 334534 a 334543 e depois pegou uma sequencia
anterior a essa.
BS Key Size Device Type Elapsed Time Completion Time
--- -- --- ---
5412167 7.44G SBT_TAPE00:01:16 17-FEB-17
BP Key: 5412205 Status: AVAILABLE Compressed: NO Tag:
TAG20170217T082705
Handle: c0090prd_Online_Mensal_ARC.dbf
Media: dc86fc0a:58861799:77ff:0005
List of Archived Logs in backup set 5412167
Thrd Seq Low SCNLow Time Next SCN Next Time
--- -- - -- -
1334534 7193428352412 17-FEB-17 7193428761667 17-FEB-17
1334535 7193428761667 17-FEB-17 7193429115293 17-FEB-17
1334536 7193429115293 17-FEB-17 7193429506973 17-FEB-17
1334537 7193429506973 17-FEB-17 7193429925266 17-FEB-17
1334538 7193429925266 17-FEB-17 7193430325138 17-FEB-17
1334539 7193430325138 17-FEB-17 7193430926041 17-FEB-17
1334540 7193430926041 17-FEB-17 7193431307535 17-FEB-17
1334541 7193431307535 17-FEB-17 7193431732417 17-FEB-17
1334542 7193431732417 17-FEB-17 7193432117973 17-FEB-17
1334543 7193432117973 17-FEB-17 7193432633395 17-FEB-17
BS Key Size Device Type Elapsed Time Completion Time
--- -- --- ---
5412168 7.43G SBT_TAPE00:01:14 17-FEB-17
BP Key: 5412206 Status: AVAILABLE Compressed: NO Tag:
TAG20170217T082705
Handle: c0090prd_Online_Mensal_ARC.dbf
Media: dc86fc0a:58861799:77ff:0005
List of Archived Logs in backup set 5412168
Thrd Seq Low SCNLow Time Next SCN Next Time
--- -- - -- -
1334424 7193393607996 17-FEB-17 7193393940341 17-FEB-17
1334425 7193393940341 17-FEB-17 7193394275225 17-FEB-17
1334426 7193394275225 17-FEB-17 7193394605085 17-FEB-17
1334427 7193394605085 17-FEB-17 7193394899098 17-FEB-17
1334428 7193394899098 17-FEB-17 7193395253237 17-FEB-17
1334429 7193395253237 17-FEB-17 7193395686298 17-FEB-17
1334430 7193395686298 17-FEB-17 7193395959821 17-FEB-17
1334431 7193395959821 17-FEB-17 7193396343379 17-FEB-17
1334432 7193396343379 17-FEB-17 7193396776060 17-FEB-17
1334433 7193396776060 17-FEB-17 7193397179895 17-FEB-17
Grato,
Ednilson
De:
sentto-1682896-121551-1487703686-ednilson.silva=jbs.com...@returns.groups.yahoo.com
[mailto:sentto-1682896-121551-1487703686-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
Em nome de jlchia...@yahoo.com.br [oracle_br]
Enviada em: terça-feira, 21 de fevereiro de 2017 16:01
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] Re: Recover database
Legal, vc comprovou então que era alguma questão menor (permissão, fita não
acessível, whatever) que estava impedindo o RMAN de restaurar sozinho os
archives necessários ok, menos mal que não era nenhuma corrupção/falha do
backup em si Só reforço a necessidade de vc fazer um Estudo aí sobre a
Viabilidade de tirar múltiplos backups de cada archive antes de os remover do
disco (removendo portanto esse DELETE INPUT geral e genérico) a fim de ter
ainda mais margem de segurança...
Sobre a sua primeira pergunta, a maneira mais comum de se listar os archives
presentes nos seus backups é um LIST ARCHIVELOG ALL, que pode ser sem argumento
nenhum (e aí mostra Todos os conhecidos pelo catálogo) quanto pode ser (por
exemplo) um LIST ARCHIVELOG ALL BACKED UP xx TIMES que mostra só os backupeados
x vezes.
Eventualmente, se nenhum desses estiver no formato exato que vc deseja, vc
pode usar as views de metadados do RMAN, como (por exemplo) a V$RMAN_OUTPUT e
