O mais impressionante é que, mesmo com a enorme quantidade de conteúdo técnico disponível hoje, ainda encontramos cenários com alto nível de desinformação e baixa maturidade em práticas essenciais dentro de ambientes corporativos.

2 pontos que eu gostaria de salientar :

1- Backup

2-Observabilidade

Esses dois pontos precisam caminhar juntos: não adianta ter uma rotina de backup se você não sabe, de fato, se ela está funcionando corretamente. Faz sentido, não é?

Com isso em mente, agora podemos avançar para a parte prática.

A Tal Rotina de data pump

#!/bin/bash

export ORACLE_PDB_SID=PDB_APP01 
export ORACLE_BASE=/u01/app/oracle 
export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1 export ORACLE_HOSTNAME=DBSERVER01 
export PATH=\(PATH:\)ORACLE_HOME/bin

#
cd /backup/datapump

/bin/mv /backup/datapump/*APP01*.gz /backup/datapump_old 2>/dev/null

DATA=$(date +%Y-%m-%d)

expdp system/SenhaFicticia123@PDB_APP01 
schemas=APP,APP_AUDIT 
directory=DP_DIR_APP01 
flashback_time=systimestamp 
dumpfile=EXPDP_APP01_${DATA}.dmp 
logfile=EXPDP_APP01_${DATA}.log

/bin/gzip *APP01*
/bin/chmod 644 *.gz *.log

Até aqui, nada além do básico — uma rotina simples e funcional.

Optei por mantê-la como estava, pois, apesar de existirem diversas oportunidades de melhoria, ela cumpria seu papel. E, naquele momento, o foco da atividade não era evoluir essa rotina, mas atuar em pontos mais críticos do ambiente.

Rotina Backup Contrab

#rotina arc - a cada 30m 
*/30 * * * * /backup/scripts_bkp/bkp_arc.sh > /backup/scripts_bkp/log_err_arc 2>&1

#inc - segunda a sabado as 21:15h
15 21 * * 1-6 /backup/scripts_bkp/bkp_inc.sh > /backup/scripts_bkp/log_err_inc 2>&1

#full - Domingo as 21h
0 21 * * 0 /backup/scripts_bkp/bkp_full.sh > /backup/scripts_bkp/log_err_full 2>&1

Com essa estratégia, conseguimos cobrir a base de dados com backups ao longo de uma semana.

Os parâmetros adotados foram definidos com base nas limitações de espaço do ambiente. Considerando a rotina de backup de archivelogs a cada 30 minutos, temos um RPO aproximado de 30 minutos — desde que todos os backups estejam íntegros e disponíveis para recuperação.

Os scripts utilizados estão disponibilizados abaixo, devidamente documentados, incluindo regras de notificação por e-mail tanto para sucesso quanto para falhas. É uma abordagem simples, mas que atende bem ao objetivo proposto.

O ambiente em questão utilizava Oracle Standard Edition e apresentava diversas limitações. Ainda assim, isso não justifica a ausência de uma estratégia de backup confiável e funcional — pelo contrário, torna essa necessidade ainda mais crítica.

Configurações Essenciais RMAN

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;

Todas as rotinas documentas e com envio de e-mail diretamente nos scripts para facilitar a Observability quando uma rotina falhar ou finalizar com sucesso.

Script Backup Full

https://github.com/francois-fiorino/Advanced-Scripts/blob/344dc099fa1c545ca3af29c45aafe5cb7db6b3f6/oracle/bkp-full

Script Backup Archive

https://github.com/francois-fiorino/Advanced-Scripts/blob/344dc099fa1c545ca3af29c45aafe5cb7db6b3f6/oracle/bkp-archive

Script Backup Incremental

https://github.com/francois-fiorino/Advanced-Scripts/blob/de12df01eb0d081218b175e30bde60552cd9ddb4/oracle/bkp-incr

Conclusão

É isso galera, nem sempre temos disponíveis as melhores condições no cliente, as melhores features ou recursos, mas o básico deve ser atendido, pelo menos é desta forma que eu penso.

Até a próxima ...

Agora vou contar para vocês o que ninguém conta sobre o exame:

Exam 1Z0-084: Oracle Database 19c: Performance Management and Tuning

Sem dúvida este é o exame mais difícil da Oracle !!!!

Inicio do Desafio

Existem conquistas que você comemora.
E existem conquistas que te transformam.

Essa com toda certeza, está me transformou em um DBA Foda!!

Aqui eu entendi uma coisa que muitos ignoram:

Saber Oracle não é o mesmo que saber Performance e Tuning de verdade.

Você pode conhecer RMAN, Data Guard, SQL, Exadata ...
Mas quando entra em temas:

• CBO e Otimizador

• estatísticas

• plano de execução

• Advisors e Tenicas diversas

…ou você entende profundamente, ou você cai.

E eu caí, mas não desisti.

Virada de Chave

Na segunda tentativa, já não era mais ignorância.

📉 Segunda tentativa — 44%

Era um confronto interno. Eu entregava alta performance nos ambientes reais, mas na hora da prova, não conseguia transpor esse conhecimento para o papel.

Melhorou? Sim.
Mas ainda não era suficiente.

Foi aqui que a chave virou:

Eu parei de estudar para a prova e comecei a estudar como um especialista.

Comecei a:

• simular cenários reais

• testar comportamento do otimizador

• analisar planos de execução na prática

• questionar o “porquê” de cada decisão tomada pelo oracle

• falar com especialistas da área, procurar entender a mentalidade de alguém que lida somente com performance no dia-a-dia

Não era mais sobre acertar questão.
Era sobre entender o mecanismo por trás, se não entender o porquê, você não aprende.

Então me dediquei pelo menos mais de 180H de montagem de laboratório, até que eu entendesse o porquê, item a item.

Aprovação

🔥 Terceira tentativa — 60% (APROVADO)

Não foi perfeito.
Foi no limite.

Mas dessa vez foi diferente.

Cada questão não era mais “chute técnico”.
Era decisão baseada em:

• experiência prática

• análise crítica

• entendimento real

E quando veio o “Passed”, eu sabia:

Não foi sorte. Foi construção, foi determinação e muito estudo.

Eu não estudei para a prova, não decorei conceito, eu simplesmente entendi os PORQUÊS...

Temas Abordas no Exame

Minhas dicas de estudos:

🔧 1. Monte laboratório — e confronte teoria com prática o tempo todo
Não leia apenas. Teste. Quebre. Simule cenários reais.
Performance tuning só se aprende vendo o comportamento do banco na prática.

🤖 2. Use IA para acelerar seus cenários de teste
Gerar massa de dados, simular problemas, criar queries complexas…
A IA pode te economizar horas de setup e te colocar direto no que importa: análise e diagnóstico.

📊 3. Domine os Advisors e ferramentas internas
Estude profundamente:

• AWR

• ADDM

• ASH

• Advisors (SQL Tuning, Segment, etc.)

Isso é extremamente cobrado — e mais importante: é o que você usa no mundo real.

🧠 4. Entenda o CBO de verdade (não superficialmente)

• Como o otimizador pensa

• Como ele estima cardinalidade

• Como escolhe planos

Se você entende isso, você deixa de reagir… e passa a antecipar o comportamento do banco.

📈 5. Aprenda a ler planos de execução como um especialista
Não é só olhar o custo.
É interpretar:

• Join methods

• Access paths

• Cardinalidade estimada vs real

• Gargalos escondidos

E principalmente: o porquê daquele plano existir.

🧪 6. Trabalhe com traces e diagnóstico profundo
10046, SQL Trace, tkprof…
Aqui você sai do “achismo” e entra no diagnóstico baseado em evidência.

⚙️ 7. Desenvolva sua própria metodologia de tuning
Pare de atuar no improviso.
Crie um processo:

1. Identificar o problema

2. Coletar evidências

3. Analisar

4. Testar hipóteses

5. Validar resultado

Isso muda completamente seu nível como DBA.

📚 8. Conheça profundamente as views V\( e GV\)
Aqui está a verdade do banco.

• Sessões

• Esperas

• Consumo de recursos

• Histórico

Se você domina essas views, você enxerga o banco por dentro.

⏱️ 9. Entenda Wait Events (de verdade)
Não decore — interprete.

• Por que está esperando?

• Onde está o gargalo?

• É CPU, IO, lock, rede?

Saber correlacionar wait events com cenários reais é um divisor de águas.

🧩 10. Entenda problemas físicos de dados

• Migrated rows

• Chained rows

E principalmente: o impacto disso na performance.

📐 11. Cardinalidade e seletividade são o jogo
Se você entende isso, você entende o CBO.

E se você entende o CBO…
você consegue influenciar o plano de execução de forma inteligente.

Conclusão

💡 O que essa jornada realmente me ensinou

Essa prova não mede só conhecimento.
Ela mede maturidade técnica.

Ela separa:

• quem executa comando de quem entende comportamento

• quando utilizar cada método, dependendo da situação ou cenário.

Tuning é um aprendizado contínuo: confronto constante de cenários e situações adversas que consolida conceitos, permite praticar e aperfeiçoar técnicas, transformando o DBA em referência.

Isto força você a sair do superficial e entrar no nível onde realmente importa, ser critico e fazer sempre a pergunta: 👉 por que o banco se comportou desta forma?

Não tive mentor nem fiz curso algum, mas mergulhei em diversas fontes e materiais — com destaque para a documentação oficial da Oracle. Meu foco foi confrontar conceitos e "meias-verdades", validando tudo na prática para solidificar o aprendizado.

🧠 A maior lição

Você não falha quando reprova.

Você falha quando: desiste ou contínua estudando do mesmo jeito

Eu precisei de 3 tentativas.
E cada uma delas foi necessária, não para me ensinar teoria, mas para me formar, me dar a visão que um especialista precisa frente a situações adversas.

Você realmente sabe a diferença entre Backupset e Image Copy no RMAN?

Mais do que isso: sabe quando usar cada estratégia e quais são as limitações práticas de cada uma em ambientes reais?

Muita gente conhece os comandos, mas nem sempre entende o impacto que a escolha do tipo de backup pode ter no tempo de recuperação do banco (RTO) e na estratégia de proteção de dados (RPO).

Por isso resolvi montar um laboratório prático, inspirado em um projeto real que atendi recentemente:

Neste projeto o requisito era diminuir o RTO de um banco de dados produtivo que tinha mais ou menos 10 TB. Nos testes realizados em um ambiente controlado de simulação de falhas, substituímos a estratégia tradicional baseada em backupset por uma abordagem utilizando Image Copy. Os resultados foram bastante expressivos: o tempo necessário para restaurar e recuperar o banco apresentou uma redução significativa, principalmente em cenários de perda de datafiles ou necessidade de recuperação completa.

A estratégia adotada foi: Image Copy + Incremental Merge

Neste artigo vou compartilhar esse laboratório, mostrando na prática, sem enrolação, as diferenças entre Backupset e Image Copy, quando cada um faz mais sentido e como essa escolha pode impactar diretamente a sua estratégia de backup e recovery.

Backupset (BACKUP AS BACKUPSET)

O que é

Um backupset é um formato proprietário do RMAN que não é uma cópia direta do datafile.

Ele contém:

. Apenas Blocos Utilizados

. Pode ter compressão

. Pode ter multiplexação

. Pode ser criptografado

. Pode ser gravado em fita (SBT)

 Características

. RMAN lê os datafiles

. Extrai somente blocos necessários

. Grava em arquivos .bkp ou .backupset 

Exemplo:

BACKUP DATABASE;
ou
BACKUP AS BACKUPSET DATABASE;

Vantagens

✔ Menor espaço
✔ Mais rápido para transferir
✔ Suporta compressão
✔ Ideal para backup em fita

✔ Permite compressão

✔ Permite multiplexação

Desvantagens

❌ Não é utilizável diretamente pelo Oracle
❌ Precisa ser restaurado antes de usar

Image Copy (BACKUP AS COPY)

O que é

Uma Image Copy é uma cópia física idêntica do datafile um datafile original -> copia byte a byte.

Exemplo:

BACKUP AS COPY DATABASE;
ou
BACKUP AS COPY DATAFILE 5;

Isso gera um arquivo igual ao datafile original.

Vantagens

✔ Pode ser usado imediatamente

✔ Permite SWITCH DATABASE TO COPY

✔ Excelente para estratégia de recuperação rápida

Desvantagens

❌ Maior uso de disco

❌ Não comprime

❌ Não multiplexa

Quando escolher Backupset

Use quando:

• O banco é grande e espaço de backup é limitado

• Você precisa de compressão

• Você faz backup para fita

• O tempo de restore não é extremamente crítico

• O ambiente tem janela de manutenção suficiente para restore completo.

• Quando o ambiente tem data guard e ele é utilizado como estratégia de contingência.

Exemplo de cenários

• Backups enviados para tape library

• Backups replicados para cloud storage

• Ambientes com RTO mais flexível

• Bancos de dados muito grandes onde armazenar cópias completas seria caro

Quando escolher Image Copy

Use quando:

• O RTO precisa ser muito baixo

• O banco é crítico

• Downtime precisa ser mínimo

• Você quer usar Incremental Merge

• Há bastante espaço em disco

• Quando você quer economizar tempo de restore.

Exemplo de cenários

• Sistemas financeiros

• E-commerce

• Bancos críticos de produção

• Ambientes de alta disponibilidade

Montagem de Laboratório

SQL> CREATE TABLESPACE ts_lab
DATAFILE '+DATADISK'
SIZE 100M;

Tablespace created.

SQL> select file_name from dba_data_files;

FILE_NAME
----------------------------------------------------
+DATADISK/ORADB/DATAFILE/system.256.1044815187
+DATADISK/ORADB/DATAFILE/sysaux.257.1044815223
+DATADISK/ORADB/DATAFILE/undotbs1.258.1044815237
+DATADISK/ORADB/DATAFILE/users.259.1044815239
+DATADISK/ORADB/DATAFILE/ts_lab.327.1228064151

Vamos criar uma tabela simples para consultar o seus dados, após restore.

CREATE TABLE objeto_simples (
id NUMBER(10) PRIMARY KEY,
nome VARCHAR2(100),
tipo VARCHAR2(20),
criado_em DATE
)
TABLESPACE TS_LAB;

--Insere dados de exemplo 
INSERT INTO objeto_simples VALUES (2, 'VIEW_EXEMPLO', 'VIEW', SYSDATE - 1);
INSERT INTO objeto_simples VALUES (1, 'TABELA_TESTE', 'TABLE', SYSDATE);
INSERT INTO objeto_simples VALUES (3, 'PROCEDIMENTO1', 'PROCEDURE', SYSDATE - 2);
INSERT INTO objeto_simples VALUES (4, 'INDICE_PRINC', 'INDEX', SYSDATE);

COMMIT;

--Verifica objeto criado (opcional)

SQL> SELECT count(*) FROM objeto_simples;

  COUNT(*)
----------
         4

Backup Usando BACKUPSET

--No Oracle Recovery Manager: 
RMAN> BACKUP TABLESPACE ts_lab; 

Starting backup at 16-MAR-2026 10:05:38 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel
ORA_DISK_1: SID=283 device type=DISK channel ORA_DISK_1: starting full
datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup
set input datafile file number=00013
name=+DATADISK/ORADB/DATAFILE/ts_lab.327.1228064151 channel ORA_DISK_1:
starting piece 1 at 16-MAR-2026 10:05:41 channel ORA_DISK_1: finished piece
1 at 16-MAR-2026 10:05:42 piece
handle=+DATADISK/ORADB/BACKUPSET/2026_03_16/nnndf0_tag20260316t100541_0.329.1228064743 tag=TAG20260316T100541 comment=NONE channel ORA_DISK_1: backup
set complete, elapsed time: 00:00:01 Finished backup at 16-MAR-2026
10:05:43 Starting Control File and SPFILE Autobackup at 16-MAR-2026
10:05:43 piece
handle=+DATADISK/ORADB/AUTOBACKUP/2026_03_16/s_1228064741.330.1228064743
comment=NONE

Finished Control File and SPFILE Autobackup at 16-MAR-2026 10:05:44

RMAN> LIST BACKUP OF TABLESPACE ts_lab;

List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------------
11      Full    1.15M      DISK        00:00:02     16-MAR-2026 17:05:41
        BP Key: 11   Status: AVAILABLE  Compressed: NO  Tag: TAG20260316T100541
        Piece Name: +DATADISK/ORADB/BACKUPSET/2026_03_16/nnndf0_tag20260316t100541_0.329.1228064743
  List of Datafiles in backup set 11
  File LV Type Ckp SCN    Ckp Time             Abs Fuz SCN Sparse Name
  ---- -- ---- ---------- -------------------- ----------- ------ ----
  13      Full 13757442   16-MAR-2026 17:05:41              NO    +DATADISK/ORADB/DATAFILE/ts_lab.327.1228064151

Simular problema

--Validar status da Tablespaces:

select TABLESPACE_NAME, STATUS from dba_tablespaces 
where tablespace_name ='TS_LAB';

TABLESPACE_NAME                STATUS
------------------------------ ---------
TS_LAB                         ONLINE

--Vamos remover o datafile.
ALTER TABLESPACE ts_lab OFFLINE IMMEDIATE;

--No ASM:
ASMCMD> rm -rf +DATADISK/oradb/datafile/TS_LAB.327.1228064151

--Vamos tentar colocar esta tbs online e vermos o erro:
SQL> ALTER TABLESPACE ts_lab online;
ALTER TABLESPACE ts_lab online
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 13 - see DBWR trace file
ORA-01110: data file 13: '+DATADISK/ORADB/DATAFILE/ts_lab.327.1228064151'

Recovery usando BACKUPSET

Agora vem o fluxo clássico - No padrão backupset

--RMAN pega o backupset e recria o datafile.

RMAN> RESTORE TABLESPACE ts_lab;

Starting restore at 16-MAR-2026 10:12:02

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=66 device type=DISK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00013 to +DATADISK/ORADB/DATAFILE/ts_lab.327.1228064151

channel ORA_DISK_1: reading from backup piece +DATADISK/ORADB/BACKUPSET/2026_03_16/nnndf0_tag20260316t100541_0.329.1228064743
channel ORA_DISK_1: piece handle=+DATADISK/ORADB/BACKUPSET/2026_03_16/nnndf0_tag20260316t100541_0.329.1228064743 tag=TAG20260316T100541
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 16-MAR-2026 10:12:06

Agora vamos aplicar redo logs, caso exista para deixar a tbs consistente e conseguir colocar a tbs ONLINE.

RMAN> RECOVER TABLESPACE ts_lab;

Starting recover at 16-MAR-2026 10:12:45
using channel ORA_DISK_1
starting media recovery media recovery
complete, elapsed time: 00:00:00

Finished recover at 16-MAR-2026 10:12:46

--Metricas obtidas.
--fim do RESTORE: 10:12:06
--início do RECOVER: 10:12:45

Colocar a tbs online:

RMAN> ALTER TABLESPACE ts_lab ONLINE;

Statement processed

Validar status da tbs recuperada.

SQL> select TABLESPACE_NAME, STATUS from dba_tablespaces 
where tablespace_name ='TS_LAB';

TABLESPACE_NAME                STATUS
------------------------------ ---------
TS_LAB                         ONLINE

SQL> SELECT count() FROM objeto_simples;

  COUNT(*)
----------
         4

Repare que ao validarmos o file name do datafile, ele foi criado usando um novo nome, isso é característico do método via backupset.

SQL> select file_name from dba_data_files; 

FILE_NAME
-----------------------------------------------
+DATADISK/ORADB/DATAFILE/system.256.1044815187
+DATADISK/ORADB/DATAFILE/sysaux.257.1044815223
+DATADISK/ORADB/DATAFILE/undotbs1.258.1044815237
+DATADISK/ORADB/DATAFILE/users.259.1044815239
+DATADISK/ORADB/DATAFILE/ts_lab.327.1228065125

Fluxo do Backupset

backupset

↓

RESTORE

↓

datafile recriado

↓

RECOVER

↓

tablespace online

Backup usando IMAGE COPY

Primeiro criar backup do tipo - image copy.

RMAN> BACKUP AS COPY TABLESPACE ts_lab;

Starting backup at 16-MAR-2026 10:17:44

using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=66 device type=DISK
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=66 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00013 name=+DATADISK/ORADB/DATAFILE/ts_lab.327.1228065125
output file name=+DATADISK/ORADB/DATAFILE/ts_lab.331.1228065467 tag=TAG20260316T101746 RECID=4 STAMP=1228040266
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 16-MAR-2026 10:17:47
Starting Control File and SPFILE Autobackup at 16-MAR-2026 10:17:47
piece handle=+DATADISK/ORADB/AUTOBACKUP/2026_03_16/s_1228040267.332.1228065467 comment=NONE

Finished Control File and SPFILE Autobackup at 16-MAR-2026 10:17:48

--Verificar o backup gerado:
RMAN> LIST COPY OF TABLESPACE ts_lab;

List of Datafile Copies
Key File S Completion Time Ckp SCN Ckp Time Sparse
4 13 A 16-MAR-2026 10:17:46 13761413 16-MAR-2026 10:17:46 NO
Name: +DATADISK/ORADB/DATAFILE/ts_lab.331.1228065467
Tag: TAG20260316T101746

Detalhe importante:

Agora no ASM temos 2 arquivos da mesma Tablespace, um copia do outro:

ASMCMD> cd datafile
ASMCMD> ls -l
Type Redund Striped Time Sys Name

DATAFILE UNPROT COARSE MAR 16 17:00:00 Y TS_LAB.327.1228065125
DATAFILE UNPROT COARSE MAR 16 17:00:00 Y TS_LAB.331.1228065467

Simular problema

--Vamos novamente remover o datafile simulando um erro.
SQL> ALTER TABLESPACE ts_lab OFFLINE IMMEDIATE;

# ASMCMD> rm -rf +DATADISK/oradb/datafile/TS_LAB.327.1228065125

Recovery usando IMAGE COPY

Vamos agora recuperar o datafile, repare que o processo será mais rápido, pois não precisa recriar o datafile, apenas fazer um switch copy e alterar a referencia no controlfile.

RMAN> SWITCH TABLESPACE ts_lab TO COPY;

using target database control file instead of 
recovery catalog
datafile 13 switched to datafile copy "+DATADISK/ORADB/DATAFILE/ts_lab.331.1228065467"

Aqui fica evidente que em um banco enorme, economizaríamos um tempo considerado de RESTORE que em uma estratégia de RTO é o fator que mais consome tempo para recuperar um banco por completo.

RMAN> RECOVER TABLESPACE ts_lab;
Starting recover at 16-MAR-2026 10:30:43
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=47 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 16-MAR-2026 10:30:46

RMAN> ALTER TABLESPACE ts_lab ONLINE;
Statement processed

--Valide a quantidade de registros na tabela, após restore.
SQL> SELECT count(*) FROM objeto_simples;

  COUNT(*)
----------
         4

Fluxo do Image Copy

image copy já existe

↓

SWITCH TO COPY

↓

RECOVER

↓

tablespace online

Conclusão

Quando falamos de estratégias de backup e recuperação, não existe uma única abordagem que funcione para todos os cenários. Cada ambiente possui suas próprias características, limitações e requisitos de negócio.

Por isso, evite ficar preso a apenas um método ou padrão. Analise o ambiente, entenda os objetivos de RPO e RTO, avalie as limitações de infraestrutura e identifique quais estratégias realmente fazem sentido para aquele contexto.

Se necessário, teste diferentes abordagens em ambientes controlados. Muitas vezes é justamente nesses testes que surgem oportunidades de melhoria que passam despercebidas no dia a dia operacional.

No final das contas, nada está escrito em pedra. O papel de quem administra bancos de dados é justamente questionar, analisar criticamente e buscar constantemente formas mais eficientes de proteger e recuperar os dados.

Faça as perguntas certas, valide as hipóteses e esteja sempre disposto a evoluir suas estratégias.

Em ambientes corporativos é comum a necessidade de provisionar múltiplos usuários com as mesmas permissões dentro do banco de dados.

Realizar a concessão manual de privilégios em centenas ou milhares de objetos pode ser um processo demorado, sujeito a erros e difícil de auditar.

Neste artigo apresento uma abordagem estruturada para:

• Criar usuários no Oracle Database

• Centralizar privilégios em uma ROLE

• Automatizar a concessão de privilégios em tabelas e objetos PL/SQL

• Executar um dry-run para validação antes de aplicar os GRANTs

• Registrar todas as operações em log

Essa abordagem é especialmente útil em ambientes com grande volume de objetos, onde a manutenção manual se torna inviável.

1. Criando uma ROLE para centralizar os privilégios

A primeira boa prática é evitar conceder privilégios diretamente aos usuários.

Em vez disso, criamos uma ROLE que centraliza os privilégios.

CREATE ROLE app_dml_role;

2. Criação dos usuários no banco de dados

Agora criamos os usuários que terão acesso ao banco.

CREATE USER user_1 IDENTIFIED BY "aDo04j28L"

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP

QUOTA UNLIMITED ON USERS;



CREATE USER user_2 IDENTIFIED BY "8178R2uxW"

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP

QUOTA UNLIMITED ON USERS;



CREATE USER user_3 IDENTIFIED BY "O7F7xI0Y5"

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP

QUOTA UNLIMITED ON USERS;



CREATE USER user_4 IDENTIFIED BY "CRF1190Kh"

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP

QUOTA UNLIMITED ON USERS;



CREATE USER user_5 IDENTIFIED BY "N8cHd9q1A"

DEFAULT TABLESPACE USERS

TEMPORARY TABLESPACE TEMP

QUOTA UNLIMITED ON USERS;

3. Concedendo privilégio de conexão

Todos os usuários precisam do privilégio básico de conexão.

GRANT CREATE SESSION TO user_1;

GRANT CREATE SESSION TO user_2;

GRANT CREATE SESSION TO user_3;

GRANT CREATE SESSION TO user_4;

GRANT CREATE SESSION TO user_5;

4. Associando a ROLE aos usuários

Agora vinculamos os usuários à role criada anteriormente.

GRANT app_dml_role TO user_1;

GRANT app_dml_role TO user_2;

GRANT app_dml_role TO user_3;

GRANT app_dml_role TO user_4;

GRANT app_dml_role TO user_5;

5. Tabela de log das operações

Antes de executar os GRANTs, criamos uma tabela para registrar todas as operações realizadas.

CREATE TABLE sec_grant_log (

  log_id      NUMBER GENERATED ALWAYS AS IDENTITY,

  log_ts      TIMESTAMP DEFAULT SYSTIMESTAMP,

  role_name   VARCHAR2(128),

  owner_name  VARCHAR2(128),

  obj_type    VARCHAR2(30),

  obj_name    VARCHAR2(128),

  stmt        CLOB,

  status      VARCHAR2(10),

  err_msg     VARCHAR2(4000)

);

6. Package para execução automatizada dos GRANTs

Specification

CREATE OR REPLACE PACKAGE sec_grant_mgr AS

  PROCEDURE grant_role_for_owners(

    p_role      IN VARCHAR2,

    p_owners    IN SYS.ODCIVARCHAR2LIST,

    p_dry_run   IN BOOLEAN DEFAULT FALSE

  );

END sec_grant_mgr;

/

Package Body

CREATE OR REPLACE PACKAGE BODY sec_grant_mgr AS

  PROCEDURE log_stmt(
    p_role   VARCHAR2,
    p_owner  VARCHAR2,
    p_type   VARCHAR2,
    p_name   VARCHAR2,
    p_stmt   CLOB,
    p_status VARCHAR2,
    p_err    VARCHAR2
  ) IS
  BEGIN
    INSERT INTO sec_grant_log(role_name, owner_name, obj_type, obj_name, stmt, status, err_msg)
    VALUES (UPPER(p_role), UPPER(p_owner), p_type, p_name, p_stmt, p_status, p_err);
  END;

  PROCEDURE exec_sql(
    p_role    VARCHAR2,
    p_owner   VARCHAR2,
    p_type    VARCHAR2,
    p_name    VARCHAR2,
    p_sql     CLOB,
    p_dry_run BOOLEAN
  ) IS
  BEGIN
    IF NOT p_dry_run THEN
      EXECUTE IMMEDIATE p_sql;
    END IF;

    log_stmt(p_role, p_owner, p_type, p_name, p_sql, 'OK', NULL);

  EXCEPTION
    WHEN OTHERS THEN
      log_stmt(p_role, p_owner, p_type, p_name, p_sql, 'ERROR', SQLERRM);
  END;

  PROCEDURE grant_role_for_owners(
    p_role      IN VARCHAR2,
    p_owners    IN SYS.ODCIVARCHAR2LIST,
    p_dry_run   IN BOOLEAN DEFAULT FALSE
  ) IS
  BEGIN

    FOR t IN (
      SELECT owner, table_name
      FROM dba_tables
      WHERE owner IN (SELECT UPPER(column_value) FROM TABLE(p_owners))
    ) LOOP
      exec_sql(
        p_role, t.owner, 'TABLE', t.table_name,
        'GRANT SELECT, INSERT, UPDATE, DELETE ON ' || t.owner || '.' || t.table_name || ' TO ' || p_role,
        p_dry_run
      );
    END LOOP;

    FOR o IN (
      SELECT owner, object_name, object_type
      FROM dba_objects
      WHERE owner IN (SELECT UPPER(column_value) FROM TABLE(p_owners))
      AND object_type IN ('PROCEDURE','FUNCTION','PACKAGE')
    ) LOOP
      exec_sql(
        p_role, o.owner, o.object_type, o.object_name,
        'GRANT EXECUTE ON ' || o.owner || '.' || o.object_name || ' TO ' || p_role,
        p_dry_run
      );
    END LOOP;

    COMMIT;

  END;

END sec_grant_mgr;
/

7. Executando um DRY-RUN

Antes de aplicar os GRANTs efetivamente, podemos simular a execução.

SQL

BEGIN

  sec_grant_mgr.grant_role_for_owners(

    p_role    => 'APP_DML_ROLE',

    p_owners  => SYS.ODCIVARCHAR2LIST('RM'),

    p_dry_run => TRUE

  );

END;

/

8. Validando os resultados da simulação

SELECT status, obj_type, COUNT(*) qtd

FROM sec_grant_log

WHERE role_name = 'APP_DML_ROLE'

GROUP BY status, obj_type

ORDER BY status, obj_type;



STATUS     OBJ_TYPE                              QTD

---------- ------------------------------ ----------

OK         FUNCTION                               45

OK         PROCEDURE                              53

OK         TABLE                                8544



SELECT stmt

FROM sec_grant_log

WHERE role_name = 'APP_DML_ROLE'

AND status = 'OK'

ORDER BY log_id;

9. Validando os grants gerados e armazenados na tabela, após simulação.

SELECT stmt

FROM sec_grant_log

WHERE role_name = 'APP_DML_ROLE'

AND status = 'OK'

ORDER BY log_id;



STMT                                                                           

--------------------------------------------------------------------------------

GRANT EXECUTE ON RM.VERIFICAGLOSAGG TO APP_DML_ROLE                            

GRANT EXECUTE ON RM.SP_AJUSTACLIENTEDUPLICADO TO APP_DML_ROLE                  

GRANT EXECUTE ON RM.P_AUDITLOG TO APP_DML_ROLE                                 

GRANT EXECUTE ON RM.P_AUDITGETDIF TO APP_DML_ROLE                              

GRANT EXECUTE ON RM.SAUGETGRUPOGASTOTISS TO APP_DML_ROLE    

 

9. Limpando o log antes da execução real, para garantir que não haja duplicidade.

TRUNCATE TABLE sec_grant_log;

10. Executando os GRANTs efetivamente

BEGIN

  sec_grant_mgr.grant_role_for_owners(

    p_role    => 'APP_DML_ROLE',

    p_owners  => SYS.ODCIVARCHAR2LIST('RM'),

    p_dry_run => FALSE

  );

END;

/

11. Validando os privilégios que foram concedidos aos usuários efetivamente.

SELECT owner, table_name, privilege, grantee

FROM dba_tab_privs

WHERE grantee = 'APP_DML_ROLE'

AND owner = 'RM';

 

OWNER TABLE_NAME PRIVILEGE GRANTEE
---------- ---------------------------------------- --------------- ---------------
RM P_AUDITGETDIF EXECUTE APP_DML_ROLE
RM SAUGETGRUPOGASTOTISS EXECUTE APP_DML_ROLE

Conclusão

Essa abordagem traz várias vantagens para ambientes Oracle:

• Centralização de permissões via ROLE

• Provisionamento consistente de usuários

• Automação de GRANTs em milhares de objetos

• Execução segura via dry-run

• Auditoria completa das operações

Esse tipo de automação é extremamente útil em ambientes corporativos com grande volume de objetos e múltiplos usuários de aplicação.

Fique à vontade em alterar a procedure e incluir outros grants necessários como DDL ou DCL.

Em ambientes Oracle Multitenant, a necessidade de clonar um PDB entre CDBs distintos é comum para refresh de ambientes, provisionamento rápido, migração controlada e consolidação. Uma das formas mais elegantes no Oracle 19c é utilizar Remote Cloning via Database Link.

Cenário do Laboratório

Origem: CDB1 contendo PDB1_RMDB

Destino: CDB2 onde será criado PDB2_RMDB

Detalhe: Ambos precisam ter

1.Pré-requisitos Técnicos

Validar LOCAL UNDO, no banco de origem:

SELECT property_name, property_value
FROM database_properties
WHERE property_name = 'LOCAL_UNDO_ENABLED';

2. Criar usuário comum para o clone remoto

No CDB de origem:

CREATE USER c##remote_clone_user IDENTIFIED BY remote_clone_user CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE TO c##remote_clone_user CONTAINER=ALL;

3. Configurar TNS no destino

Este será o dblink utilizado para capturar os dados a partir da origem e clonar o pdb no destino.

remote_cdb =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.18.10)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = pdb3)
    )
  )

4. Criando o Database Link

CREATE DATABASE LINK clone_link
  CONNECT TO c##remote_clone_user IDENTIFIED BY remote_clone_user
  USING 'remote_cdb';

Valide o dblink antes de iniciar a atividade:

SQL> select sysdate from dual@clone_link;

SYSDATE

---------

23-FEB-26

5. Executando o Remote Clone

No servidor de destino, inicie o clone.

SQL> CREATE PLUGGABLE DATABASE PDB2_RMDB
FROM PDB1_RMDB@clone_link;

5.1. Evidências no alert.log

Completed: CREATE PLUGGABLE DATABASE PDB2_RMDB FROM PDB1_RMDB@clone_link

2026-02-23T17:14:31.465239-03:00

PDB2_RMDB(4):Endian type of dictionary set to little

2026-02-23T17:14:33.344149-03:00

****************************************************************

Pluggable Database PDB2_RMDB with pdb id - 4 is created as UNUSABLE.

If any errors are encountered before the pdb is marked as NEW,

then the pdb must be dropped

local undo-1, localundoscn-0x000000000000012b

****************************************************************

2026-02-23T17:14:37.703009-03:00

Applying media recovery for pdb-4099 from SCN 592315319879 to SCN 592318035910

Remote log information: count-1

thr-1,seq-20746,logfile-+ARCH/RMDB/partial_archivelog/2026_02_23/thread_1_seq_20746.342.1225991677,los-592315312478,nxs-18446744073709551615,maxblks-17452

PDB2_RMDB(4):Media Recovery Start

2026-02-23T17:14:37.719435-03:00

PDB2_RMDB(4):Serial Media Recovery started

PDB2_RMDB(4):max_pdb is 5

2026-02-23T17:14:38.141677-03:00

PDB2_RMDB(4):Media Recovery Log +ARCH/RMDB/partial_archivelog/2026_02_23/thread_1_seq_20746.342.1225991677

2026-02-23T17:14:38.467834-03:00

PDB2_RMDB(4):Incomplete Recovery applied until change 592318035910 time 02/23/2026 17:14:35

2026-02-23T17:14:38.484103-03:00

PDB2_RMDB(4):Media Recovery Complete (RMDB)

PDB2_RMDB(4):Pluggable database PDB2_RMDB pseudo opening

2026-02-23T17:14:38.737473-03:00

PDB2_RMDB(4):SUPLOG: Initialize PDB SUPLOG SGA, old value 0x0, new value 0x18

PDB2_RMDB(4):Autotune of undo retention is turned on.

2026-02-23T17:14:39.505291-03:00

PDB2_RMDB(4):Undo initialization recovery: Parallel FPTR failed: start:1801041217 end:1801041235 diff:18 ms (0.0 seconds)

PDB2_RMDB(4):Undo initialization recovery: err:0 start: 1801041210 end: 1801041442 diff: 232 ms (0.2 seconds)

2026-02-23T17:14:39.783233-03:00

PDB2_RMDB(4):[4108367] Successfully onlined Undo Tablespace 2.

PDB2_RMDB(4):Undo initialization online undo segments: err:0 start: 1801041442 end: 1801041513 diff: 71 ms (0.1 seconds)

PDB2_RMDB(4):Undo initialization finished serial:0 start:1801041210 end:1801041561 diff:351 ms (0.4 seconds)

PDB2_RMDB(4):Database Characterset for PDB2_RMDB is WE8MSWIN1252

PDB2_RMDB(4):Pluggable database PDB2_RMDB pseudo closing

PDB2_RMDB(4):JIT: pid 4108367 requesting stop

PDB2_RMDB(4):Closing sequence subsystem (18980911116255).

PDB2_RMDB(4):Buffer Cache flush started: 4

PDB2_RMDB(4):Buffer Cache flush finished: 4

2026-02-23T17:14:41.231833-03:00

Completed: CREATE PLUGGABLE DATABASE PDB2_RMDB FROM PDB1_RMDB@clone_link

2026-02-23T17:39:39.513401-03:00

6. Abrindo o PDB

ALTER PLUGGABLE DATABASE PDB2_RMDB OPEN;

6.1 Evidências do Alert.log

ALTER PLUGGABLE DATABASE PDB2_RMDB OPEN

2026-02-23T17:39:39.525650-03:00

PDB2_RMDB(4):Pluggable database PDB2_RMDB opening in read write

PDB2_RMDB(4):SUPLOG: Initialize PDB SUPLOG SGA, old value 0x0, new value 0x18

PDB2_RMDB(4):Autotune of undo retention is turned on.

PDB2_RMDB(4):Endian type of dictionary set to little

2026-02-23T17:39:40.932091-03:00

PDB2_RMDB(4):Undo initialization recovery: Parallel FPTR complete: start:1802542564 end:1802542662 diff:98 ms (0.1 seconds)

PDB2_RMDB(4):Undo initialization recovery: err:0 start: 1802542559 end: 1802542662 diff: 103 ms (0.1 seconds)

2026-02-23T17:39:42.518603-03:00

PDB2_RMDB(4):[4108367] Successfully onlined Undo Tablespace 2.

PDB2_RMDB(4):Undo initialization online undo segments: err:0 start: 1802542662 end: 1802544248 diff: 1586 ms (1.6 seconds)

PDB2_RMDB(4):Undo initialization finished serial:0 start:1802542559 end:1802544297 diff:1738 ms (1.7 seconds)

PDB2_RMDB(4):Deleting old file#8 from file$

PDB2_RMDB(4):Deleting old file#9 from file$

PDB2_RMDB(4):Deleting old file#10 from file$

PDB2_RMDB(4):Deleting old file#11 from file$

PDB2_RMDB(4):Deleting old file#12 from file$

PDB2_RMDB(4):Deleting old file#13 from file$

PDB2_RMDB(4):Deleting old file#14 from file$

PDB2_RMDB(4):Deleting old file#15 from file$

PDB2_RMDB(4):Deleting old file#16 from file$

PDB2_RMDB(4):Deleting old file#17 from file$

PDB2_RMDB(4):Deleting old file#18 from file$

PDB2_RMDB(4):Deleting old file#19 from file$

PDB2_RMDB(4):Deleting old file#20 from file$

PDB2_RMDB(4):Deleting old file#21 from file$

PDB2_RMDB(4):Deleting old file#22 from file$

PDB2_RMDB(4):Adding new file#102 to file$(old file#8).             fopr-1, newblks-1728000, oldblks-26880

PDB2_RMDB(4):Adding new file#103 to file$(old file#9).             fopr-1, newblks-211840, oldblks-21120

PDB2_RMDB(4):Adding new file#104 to file$(old file#10).             fopr-1, newblks-819840, oldblks-7680

PDB2_RMDB(4):Adding new file#105 to file$(old file#11).             fopr-1, newblks-640, oldblks-640

PDB2_RMDB(4):Adding new file#106 to file$(old file#12).             fopr-1, newblks-4194302, oldblks-131072

PDB2_RMDB(4):Adding new file#107 to file$(old file#13).             fopr-1, newblks-4194302, oldblks-131072

PDB2_RMDB(4):Adding new file#110 to file$(old file#14).             fopr-1, newblks-131072, oldblks-131072

PDB2_RMDB(4):Adding new file#111 to file$(old file#15).             fopr-1, newblks-489472, oldblks-131072

PDB2_RMDB(4):Adding new file#112 to file$(old file#17).             fopr-1, newblks-131072, oldblks-131072

PDB2_RMDB(4):Adding new file#113 to file$(old file#18).             fopr-1, newblks-131072, oldblks-131072

PDB2_RMDB(4):Adding new file#108 to file$(old file#20).             fopr-1, newblks-3638272, oldblks-131072

PDB2_RMDB(4):Adding new file#109 to file$(old file#21).             fopr-1, newblks-3177472, oldblks-131072

PDB2_RMDB(4):Adding new file#114 to file$(old file#22).             fopr-1, newblks-2918400, oldblks-12800

PDB2_RMDB(4):Successfully created internal service PDB2_RMDB at open

2026-02-23T17:39:43.638607-03:00

****************************************************************

Post plug operations are now complete.

Pluggable database PDB2_RMDB with pdb id - 4 is now marked as NEW.

****************************************************************

PDB2_RMDB(4):Database Characterset for PDB2_RMDB is WE8MSWIN1252

2026-02-23T17:39:49.052903-03:00

PDB2_RMDB(4):JIT: pid 4108367 requesting full stop

2026-02-23T17:39:55.253777-03:00

Violations: Type: 2, Count: 3

PDB2_RMDB(4):***************************************************************

PDB2_RMDB(4):WARNING: Pluggable Database PDB2_RMDB with pdb id - 4 is

PDB2_RMDB(4):         altered with errors or warnings. Please look into

PDB2_RMDB(4):         PDB_PLUG_IN_VIOLATIONS view for more details.

PDB2_RMDB(4):***************************************************************

PDB2_RMDB(4):SUPLOG: Set PDB SUPLOG SGA at PDB OPEN, old 0x18, new 0x0 (no suplog)

2026-02-23T17:40:03.101257-03:00

PDB2_RMDB(4):Opening pdb with Resource Manager plan: DEFAULT_PLAN

PDB2_RMDB(4):joxcsys_required_dirobj_exists: directory object exists with required path /u01/app/oracle/product/19.0.0.0/dbhome_1/javavm/admin/, pid 4108367 cid 4

2026-02-23T17:40:04.120041-03:00

Pluggable database PDB2_RMDB opened read write

Completed: ALTER PLUGGABLE DATABASE PDB2_RMDB OPEN

7. Verificando PDB_PLUG_IN_VIOLATIONS

Valide se há violações ao abrir o PDB. No meu caso, não foram detectadas ocorrências e as atividades prosseguiram. Caso encontre alguma violação, realize as correções antes de continuar para evitar divergências nos dados.

SELECT name, cause, type, message, status
FROM pdb_plug_in_violations
WHERE name = 'PDB2_RMDB';

Esse warning é bem típico após plug/clone de PDB: ele está dizendo que no PDB clonado o componente/option “SDO” (Oracle Spatial / Locator) não está instalado (aparece como NULL), enquanto no CDB raiz ele está instalado/registrado como 19.0.0.0.0. Por isso o PDB_PLUG_IN_VIOLATIONS registra OPTION / WARNING / PENDING.

Temos também warning de parâmetros:

Esses aqui:

• pga_aggregate_target mismatch: Previous 2032M Current 2G

• session_cached_cursors mismatch: Previous 200 Current 50

São warnings de parâmetro do CDB no momento do plug/clone.

Em geral:

• não quebram o PDB

• são só “diferença de configuração” registrada como PENDING

Mas vamos arrumar.

8. Warnings de Parâmetros:

No CDB (não no PDB), ajuste:

alter system set session_cached_cursors=200 scope=spfile;
alter system set pga_aggregate_target=2032M scope=both;

8.1 Warnings de Option:

Repita este processo para todos os PDBS que tiverem a VIOLATION registrada.

alter session set container = PDB1_RMDB;
@?/md/admin/catmd.sql
@?/rdbms/admin/utlrp.sql

alter session set container = PDB2_RMDB;
@?/md/admin/catmd.sql
@?/rdbms/admin/utlrp.sql

Verifique se o status da OPTION consta como VALID.

Anteriormente inexistente, a opção foi instalada com sucesso.

Aproveite e compile tudo.

select comp_id, version, status
from dba_registry
where comp_id='SDO';

Para aplicar as alterações de parâmetros e corrigir as violações, reinicie os PDBs e valide o status em seguida.

alter pluggable database PDB1_RMDB close immediate;
alter pluggable database PDB1_RMDB open;

alter pluggable database PDB2_RMDB close immediate;
alter pluggable database PDB2_RMDB open;

SQL> show pdbs;

CON_ID CON_NAME                       OPEN MODE  RESTRICTED

---------- ------------------------------ ---------- ----------

2 PDB$SEED                       READ ONLY  NO

3 PDB1_RMDB                      READ WRITE NO

4 PDB2_RMDB                      READ WRITE NO

col cause for a25
col time for a25
col message for a80
select name, type, cause, status, time, message
from pdb_plug_in_violations
where name IN ('PDB1_RMDB', 'PDB2_RMDB')
and message like '%SDO%'
order by time desc;

Conclusão

Remote PDB Cloning no Oracle 19c permite clonagem consistente, auditável e rápida entre CDBs, eliminando processos manuais como unplug/plug via XML ou restore físico tradicional.

Em ambientes corporativos com Oracle Linux, especialmente em cenários com RAC, ASM, SAN ou ambientes virtualizados, é comum surgir a seguinte dúvida: como descobrir quando um disco foi criado ou quando foi apresentado ao sistema operacional?

Quem nunca? precisou expandir um Disk Group no ASM?

A primeira pergunta que vem a cabeça é a seguinte, dentre os 20 discos que tenho aqui, qual devo adicionar, sem sobrepor nenhum disco existe ou gerar algum problema?

Este artigo explica de forma técnica e estruturada as formas de você se certificar e ter segurança antes de conduzir esta atividade, que apesar de simples, se não tiver atenção pode gerar um problemão.

1. O Linux não guarda a data real de criação do disco

O Linux não armazena a data física de fabricação do disco nem a data de criação da LUN na storage. Ele registra apenas quando o kernel detectou o dispositivo, quando o device node foi criado e quando o file system foi criado.

2. Ver quando o disco foi detectado pelo kernel

Utilize journalctl para consultar logs do kernel, aqui será listado por data de evento:

journalctl -k | grep -i sd

journalctl -k --since "2026-02-20" | grep sd

Alternativamente, utilize dmesg:

dmesg | grep -i sd

No meu cenário o disco foi entregue logo pela manhã pela equipe de Linux, então por aqui já consigo localizar qual o disco que posso utilizar.

3. Ver quando o device foi criado em /dev

Comando para verificar ctime do device:

stat /dev/sdg

4. Listar discos com informações técnicas completas

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL,SERIAL

Esta etapa é fundamental para identificar o tamanho, a unidade e o tipo de disco. Note que a sequência exibida corresponde exatamente à ordem em que os discos foram apresentados ao sistema

Recomendação: Correlacione a data obtida nos passos anteriores ao tamanho exigido para assegurar a rastreabilidade das informações.

5. Script para ordenar discos por data de criação do device

Aqui este script absorve diversas informações e ordena do mais antigo para o mais novo, assim fica muito fácil saber qual o disco correto.

disks="\((lsblk -dn -o NAME,TYPE | awk '\)2=="disk"{print \(1}')"
journalctl -k -o short-iso --no-pager \
| awk -v disks="\)disks" '
BEGIN{
n=split(disks,a," ");
for(i=1;i<=n;i++) want[a[i]]=1;
}
# exemplos que pegamos:
# "... kernel: sdb: ..."
# "... kernel: sd 2:0:0:0: [sdb] ..."
/ kernel: / {
for(d in want){
if (!seen[d] && (\(0 ~ (""d"") || \)0 ~ (" kernel: " d ":")) ){
seen[d]=1;
first[d]=$1; # timestamp ISO
}
}
}
END{
for(d in want){
if (first[d]!="") print "/dev/" d, first[d];
else print "/dev/" d, "NOT_FOUND";
}
}' \
| sort -k2

6. Script para ordenar discos conforme evento do kernel por data de criação do device

journalctl -k -o short-iso --no-pager | egrep -i "Attached SCSI disk|sd[a−z]+| kernel: sd[a-z]+:"

Conclusão Técnica

A identificação do momento em que um disco é disponibilizado ao Oracle Linux pode ser realizada por meio de múltiplas fontes, como a correlação de logs do kernel (dmesg), metadados do filesystem, inventários de storage e históricos do hypervisor. Em ambientes críticos, como RAC e ASM, é indispensável documentar as alterações e validar a redundância via multipath antes da criação de disk groups." Oracle Docs - ASM Storage.