⚠️ CONTÉM TEXTO MELHORADO POR AI – E TA TUDO BEM (SE SOUBER USAR 🤭)⚠️

Agora um pouco sobre a arquitetura do data bloco e rowid no Oracle:

Descrição da Estrutura:

1. Database Block: O bloco de dados é a menor unidade de armazenamento no Oracle. Dentro dele, são armazenados vários pedaços de linha (row pieces), além de informações de controle e metadados que ajudam a gerenciar o armazenamento.
2. Row Piece: Um pedaço de linha (row piece) é uma parte de uma linha de dados que pode estar completa em um único bloco ou distribuída em vários blocos (chaining ou migration). Ele contém todas as informações relacionadas aos dados da linha.
3. Row Header: O cabeçalho da linha inclui informações de controle sobre a linha armazenada, como:
   • Row Overhead: Espaço reservado para informações de controle, como status da transação associada à linha e flags de bloqueio.
   • Number of Columns: O número de colunas armazenadas na linha.
4. Column Data:
   • Cluster Key ID (se for clustered): Identificação da chave de cluster (caso a tabela faça parte de um cluster).
   • ROWID of Chained Row Pieces (se houver): Se a linha estiver fragmentada em vários blocos, o ROWID (localização da linha) dos outros pedaços de linha será armazenado aqui.
   • Column Length: Indica o tamanho de cada coluna.
   • Column Value: O valor real da coluna é armazenado nessa parte, onde cada coluna tem seu comprimento e valor específicos.

1. Object ID (OOOOOOO) – Representado em vermelho, com 4 bytes de tamanho. Esta parte identifica o objeto no banco de dados (como uma tabela ou índice).
2. Datafile Number (OBBOFLEBF) – Representado em azul, com 1,5 bytes de tamanho. Refere-se ao número do arquivo de dados onde o bloco específico reside.
3. Block Number (BBBBBB) – Representado em verde, com 2,5 bytes de tamanho. Indica o número do bloco dentro do arquivo de dados onde a linha está armazenada.
4. Row Number (BBBBBBR) – Representado em preto, com 2 bytes de tamanho. Identifica a linha específica dentro do bloco de dados.

1. Identificação de Blocos Corrompidos

Primeiramente, é necessário identificar os blocos corrompidos no banco de dados. O Oracle mantém uma tabela de sistema chamada V$DATABASE_BLOCK_CORRUPTION que lista todos os blocos identificados como corrompidos:

Você pode se atentar ao erro do Oracle:

ORA-01578: ORACLE data block corrupted (file # X, block # Y)

Nessa mensagem de erro podemos notar que existe ali o identificador do datafile e do bloco em questão.

Para checar o datafile use a query:

SELECT file_name
FROM dba_data_files
WHERE file_id = <file#>;

Para checar o bloco corrompido, pode usar:

RMAN> BLOCKRECOVER CORRUPION LIST;
SQL> 
COLUMN owner FORMAT A20
COLUMN segment_name FORMAT A30

SELECT DISTINCT owner, segment_name
FROM   v$database_block_corruption dbc
       JOIN dba_extents e ON dbc.file# = e.file_id AND dbc.block# BETWEEN e.block_id and e.block_id+e.blocks-1
ORDER BY 1,2;

Essa tabela é populada automaticamente após verificações de integridade realizadas por comandos como DBV (Data Block Verifier) ou após erros de leitura durante operações no banco de dados.

Outra forma de verificar corrupção de blocos é através de:

• Alert Log: mensagens de erro indicando falha de leitura de blocos.
• DBVERIFY: uma ferramenta externa que faz varreduras em datafiles.

dbv file=/path/to/datafile.dbf blocksize=8192

2. Recuperação de Blocos Corrompidos com RMAN

Após identificar o(s) bloco(s) corrompido(s), podemos usar o RMAN para a recuperação. O processo pode ser feito enquanto o banco de dados está aberto, reduzindo o tempo de inatividade.

Etapas para recuperação:

1. Conectar ao RMAN:

 rman target /

2. Executar o comando de recuperação de bloco: Você pode especificar o arquivo de dados e o número de bloco diretamente:

RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 12345;

Para recuperar vários blocos de uma vez:

RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 12345, 12346, 12347;

3. Verificar se os blocos foram recuperados: Após a execução do comando BLOCKRECOVER, você pode verificar novamente a visão V$DATABASE_BLOCK_CORRUPTION para garantir que os blocos não estão mais corrompidos:

SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;

3. Examinando o Conteúdo de Blocos de Dados

Para entender o conteúdo de um bloco de dados específico, o Oracle oferece um método de “dumper” de blocos. Esse procedimento pode ser útil para verificar o que está gravado no bloco, como registros de tabelas.

Passos para realizar o dump de um bloco:

1. Identifique o número do bloco, número do arquivo de dados e objeto onde o registro está armazenado. Você pode usar a query abaixo para localizar o arquivo e o número do bloco de uma linha específica:

SQL> SELECT tablespace_name, segment_type, owner, segment_name
        FROM dba_extents
       WHERE file_id = <file#>
         AND <block#> BETWEEN block_id AND block_id + blocks - 1;

SQL> 
COLUMN ROWID FORMAT A18
COLUMN OB_ID FORMAT 99999
COLUMN FILE_ID FORMAT 9
COLUMN BL_NUM FORMAT 99999
COLUMN ROW_NUM FORMAT 99
COLUMN OWNER FORMAT A2
COLUMN OBJECT_NAME FORMAT A9
COLUMN FILE_NAME FORMAT A71
COLUMN FILE_NAME FORMAT A71
COLUMN TABLESPACE_NAME FORMAT A15
SELECT tr.rowid,
       dbms_rowid.rowid_object(tr.rowid) AS OB_ID,
       dbms_rowid.rowid_relative_fno(tr.rowid) AS FILE_ID,
       dbms_rowid.rowid_block_number(tr.rowid) AS BL_NUM,
       dbms_rowid.rowid_row_number(tr.rowid) AS ROW_NUM,
       ob.owner,
       ob.object_name,
       df.file_name,
       df.tablespace_name
  FROM sys.dba_brabo_tb tr
 INNER JOIN dba_objects ob
    ON ob.object_id = dbms_rowid.rowid_object(tr.rowid)
 INNER JOIN dba_data_files df
    ON df.file_id = dbms_rowid.rowid_relative_fno(tr.rowid)
 WHERE tr.dba_brabo_alunos = 666;

COLUMN file_id          FORMAT 99999                                                       -- Número do arquivo relativo
COLUMN block_id         FORMAT 9999999                                                     -- Número do bloco no arquivo
COLUMN row_number       FORMAT 99999                                                       -- Número da linha no bloco
COLUMN rows_per_block   FORMAT 99999                                                       -- Total de linhas no bloco
COLUMN rowid            FORMAT A18                                                         -- ROWID do registro
COLUMN file_name        FORMAT A50                                                         -- Nome do arquivo de dados
COLUMN block_size_kb    FORMAT 999999                                                      -- Tamanho do bloco em KB
COLUMN total_blocks     FORMAT 999999                                                      -- Total de blocos
COLUMN segment_name     FORMAT A30                                                         -- Nome do segmento
COLUMN total_rows       FORMAT 99999999                                                    -- Total de linhas estimadas
COLUMN avg_row_length   FORMAT 9999                                                        -- Tamanho médio de uma linha

SELECT 
    A.ROWID AS row_id,                                                                     -- ROWID do registro
    DBMS_ROWID.ROWID_RELATIVE_FNO(A.ROWID) AS file_id,                                     -- Número relativo do arquivo
    DBMS_ROWID.ROWID_BLOCK_NUMBER(A.ROWID) AS block_id,                                    -- Número do bloco no arquivo
    DBMS_ROWID.ROWID_ROW_NUMBER(A.ROWID) AS row_number,                                    -- Número da linha dentro do bloco
    COUNT(*) OVER (PARTITION BY DBMS_ROWID.ROWID_BLOCK_NUMBER(A.ROWID)) AS rows_per_block, -- Total de linhas no bloco
    T.FILE_NAME AS file_name,                                                              -- Nome do arquivo de dados correspondente
    T.BYTES/1024 AS block_size_kb,                                                         -- Tamanho do bloco em KB
    T.BLOCKS AS total_blocks,                                                              -- Total de blocos alocados
    B.SEGMENT_NAME AS segment_name,                                                        -- Nome do segmento associado
    S.NUM_ROWS AS total_rows,                                                              -- Total de linhas estimadas na tabela
    S.AVG_ROW_LEN AS avg_row_length                                                        -- Tamanho médio de uma linha na tabela
FROM 
    DBA_BRABO_TB A
LEFT JOIN 
    DBA_DATA_FILES T
ON 
    T.RELATIVE_FNO = DBMS_ROWID.ROWID_RELATIVE_FNO(A.ROWID)                                -- Relaciona arquivo relativo com DBA_DATA_FILES
LEFT JOIN 
    DBA_SEGMENTS B
ON 
    B.SEGMENT_NAME = 'DBA_BRABO_TB' AND B.OWNER = 'SEU_OWNER'                         -- Ajuste o OWNER conforme necessário
LEFT JOIN 
    DBA_TABLES S
ON 
    S.TABLE_NAME = 'DBA_BRABO_TB' AND S.OWNER = 'SEU_OWNER'                           -- Ajuste o OWNER conforme necessário
WHERE 
    ROWNUM <= 1000
ORDER BY 
    file_id, block_id, row_number;

2. Usar o comando ALTER SYSTEM DUMP para fazer o dump do bloco: Para fazer o dump do bloco, utilize o seguinte comando:

O comando ALTER SYSTEM DUMP DATAFILE é uma instrução no Oracle que permite extrair informações detalhadas sobre um bloco específico dentro de um arquivo de dados. Essa instrução é usada para diagnosticar problemas de corrupção de bloco, entender a estrutura do bloco, ou obter detalhes sobre os dados contidos em um bloco específico no banco de dados.

 SQL> ALTER SYSTEM DUMP DATAFILE 4 BLOCK 12345;

Isso irá gerar um arquivo de dump no diretório de logs do Oracle, geralmente localizado em $ORACLE_HOME/diag.

3. Analisar o arquivo de dump: O dump contém informações hexadecimais e registros detalhados sobre o conteúdo do bloco. O dump vai incluir cabeçalhos, transações ativas ou inativas, e os dados efetivos gravados nesse bloco.
4. Isso é coisa antiga, lá pra Oracle 7 e 8, mas ainda funfa.

Dump file /u01/app/oracle/diag/rdbms/dbabrabo/trace/orcl_ora_12345.trc
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1
System name:    Linux
Node name:      dbabrabo01
Release:        4.18.0-80.el8.x86_64
Version:        #1 SMP Wed Apr 24 11:50:52 EDT 2019
Machine:        x86_64
Instance name: dbabrabo01
Redo thread mounted by this instance: 1
Oracle process number: 45
Unix process pid: 12345, image: oracle@dbabrabo01

*** 2024-10-21 14:35:10.123456 +00:00
*** SESSION ID:(12345.6789) 2024-10-21 14:35:10.123456
*** CLIENT ID:() 2024-10-21 14:35:10.123456
*** SERVICE NAME:(SYS$USERS) 2024-10-21 14:35:10.123456
*** MODULE NAME:(sqlplus@dbabrabo01 (TNS V1-V3)) 2024-10-21 14:35:10.123456
*** ACTION NAME:() 2024-10-21 14:35:10.123456

Start dump data blocks tsn: 4 file#: 4 minblk 12345 maxblk 12345
Block dump from cache:
Dump of buffer cache at level 4 for tsn=4 rdba=16777221

buffer tsn: 4 rdba: 0x01003039 (4/12345)
scn: 0x0000.01234567 seq: 0x01 flg: 0x06 tail: 0x567890ab
frmt: 0x02 chkval: 0xa1d7 type: 0x06=trans data

Block header dump:  0x01003039
 Object id on Block? Y
 seg/obj: 0x456789  csc: 0x00.12345678  itc: 3  flg: O-
  brn: 0  bdba: 0x01003038 ver: 0x01 opc: 0
  inc: 0  exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0009.001.00001234 0x01800012.3456789f C---    0 scn 0x0000.01234567
0x02 0x0012.002.00004567 0x01800012.345679ab --U-    2 scn 0x0000.01234568
0x03 0x0034.001.00007890 0x01800012.34567abc ----    3 scn 0x0000.01234569

Data Block:
-----------------------------------------------------------------------------
tsiz: 0x1fa0
flag: 0x2
nrid:  0x01003039
col  0: [ 3]  c1 02 03
col  1: [ 2]  c1 04
col  2: [ 4]  c1 05 c1 06
col  3: [ 8]  c2 01 00 00 00 07 08 09
row#0[8018] flag: C
lock: 2
col  0: [ 2] 80 80
col  1: [ 6] 80 80 81 81 82 82
col  2: [ 1] 80
col  3: [ 3] 00 00 00

Neste exemplo, o dump mostra o cabeçalho do bloco, identificadores de objetos, o estado de transações e registros de mudanças. Isso pode ser útil em casos onde é necessário analisar a causa da corrupção ou o estado de uma transação em andamento.

• Block header dump: 0x010032a8: O cabeçalho do bloco que está sendo “despejado”. O valor 0x010032a8 é o endereço hexadecimal do bloco.
• Object id on Block? Y: Indica que existe um ID de objeto associado ao bloco (neste caso, “Y” para “Yes”).
• seg/obj: 0x19b8: Este é o identificador de segmento ou objeto (ID de objeto 0x19b8).
• csc: 0x00.2f4c43: Este é o SCN (System Change Number) correspondente ao bloco.
• itl: 2: Indica o número de interested transaction list (ITL) slots no bloco. Isso significa que até 2 transações podem ser controladas dentro do bloco.
• Itl Xid Uba Flag Lck Scn/Fsc: Esses são os detalhes das transações ativas no bloco:
• Xid: Transaction ID (ID da transação).
• Uba: Undo Block Address.
• Flag: Flags indicando o status da transação (C indica commit).
• Lck: Lock.
• Scn/Fsc: System Change Number ou Free Space Checkpoint.
• data_block_dump,data header at 0x7f5f332e900: Início do dump dos dados no bloco. O endereço do cabeçalho de dados começa em 0x7f5f332e900.
• tsiz: 0x1f78: O tamanho do bloco de dados.
• checksum: 0x39cb: O checksum do bloco, utilizado para garantir a integridade dos dados.

4. Recuperação usando Backup Incremental (Opcional)

Se você não tiver backup de bloco específico ou se o RMAN não conseguir recuperar os blocos por qualquer motivo, você pode usar um backup incremental para recuperar blocos corrompidos:

1. Faça um backup incremental do banco de dados:

   RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

2. Execute a recuperação baseada no backup incremental:

   RMAN> RECOVER BLOCK DATAFILE 4 BLOCK 12345;

Essa abordagem aplica blocos saudáveis a partir do backup incremental, corrigindo os blocos corrompidos no banco de dados de produção.

5. Verificando a Correção do Bloco

Após a recuperação, o Oracle realiza automaticamente uma validação para garantir que o bloco foi restaurado corretamente. No entanto, você pode validar manualmente usando o comando:

Versão comum (sem ASM):

dbv file=/path/to/datafile.dbf blocksize=8192

DBVERIFY: Release 19.0.0.0.0 - Production on Mon Oct 21 14:42:33 2024

Copyright (c) 1982, 2024, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = /path/to/datafile.dbf
DBVERIFY - Verification complete

Total Pages Examined         : 64000
Total Pages Processed (Data) : 32000
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 16000
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 16000
Total Pages Processed (Seg)  : 0
Total Pages Empty            : 0
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 1123456789 (0.1123456789)

Versão do ASM:

dbv USERID=SYS/***** file=+DATAC1/datafiles/users01.dbf logfile=/tmp/dbv_dbabrabo.log

DBVERIFY: Release 19.0.0.0.0 - Production on Mon Oct 21 15:35:12 2024

Copyright (c) 1982, 2024, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = +DATAC1/datafiles/users01.dbf
DBVERIFY - Verification complete

Total Pages Examined         : 32000
Total Pages Processed (Data) : 16000
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 8000
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 8000
Total Pages Empty            : 0
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 123456789 (0.123456789)

Isso garantirá que o bloco foi corrigido sem outros erros.

6. Recuperação de Blocos Corrompidos com DBMS_REPAIR

Exemplo oriundos do mestre Tim Hall

O pacote DBMS_REPAIR do Oracle permite identificar e tratar blocos corrompidos no banco de dados. Diferentemente de outros métodos, ele não apenas detecta, mas também permite “marcar” blocos danificados para serem ignorados por operações de DML.

Criação das Tabelas Administrativas

Para gerenciar os blocos corrompidos, duas tabelas administrativas devem ser criadas:: uma para armazenar informações dos blocos corrompidos e outra para guardar chaves órfãs de índices.

BEGIN
  DBMS_REPAIR.admin_tables (
    table_name => 'TBL_CORRUPCAO',
    table_type => DBMS_REPAIR.repair_table,
    action     => DBMS_REPAIR.create_action,
    tablespace => 'USERS');

  DBMS_REPAIR.admin_tables (
    table_name => 'CHAVES_ORFAS',
    table_type => DBMS_REPAIR.orphan_table,
    action     => DBMS_REPAIR.create_action,
    tablespace => 'USERS');
END;
/

Verificação de Corrupção na Tabela

Após a criação das tabelas administrativas, a rotina CHECK_OBJECT pode ser usada para verificar a existência de blocos corrompidos em uma tabela específica.

SET SERVEROUTPUT ON
DECLARE
  v_blocos_corrompidos INT;
BEGIN
  v_blocos_corrompidos := 0;
  DBMS_REPAIR.check_object (
    schema_name       => 'DBABRABO',
    object_name       => 'CLIENTES',
    repair_table_name => 'TBL_CORRUPCAO',
    corrupt_count     => v_blocos_corrompidos);
  DBMS_OUTPUT.put_line('Blocos corrompidos detectados: ' || TO_CHAR(v_blocos_corrompidos));
END;
/

Marcação de Blocos Corrompidos

Se houver blocos corrompidos, eles podem ser “marcados” para serem ignorados durante as operações de DML.

SET SERVEROUTPUT ON
DECLARE
  v_blocos_corrigidos INT;
BEGIN
  v_blocos_corrigidos := 0;
  DBMS_REPAIR.fix_corrupt_blocks (
    schema_name       => 'DBABRABO',
    object_name       => 'CLIENTES',
    object_type       => DBMS_REPAIR.table_object,
    repair_table_name => 'TBL_CORRUPCAO',
    fix_count         => v_blocos_corrigidos);
  DBMS_OUTPUT.put_line('Blocos marcados como corrompidos: ' || TO_CHAR(v_blocos_corrigidos));
END;
/

Identificação de Chaves Órfãs em Índices

Após marcar os blocos corrompidos, os índices associados devem ser verificados para identificar chaves órfãs.

SET SERVEROUTPUT ON
DECLARE
  v_chaves_orfas INT;
BEGIN
  v_chaves_orfas := 0;
  DBMS_REPAIR.dump_orphan_keys (
    schema_name       => 'DBABRABO',
    object_name       => 'IDX_CLIENTES',
    object_type       => DBMS_REPAIR.index_object,
    repair_table_name => 'TBL_CORRUPCAO',
    orphan_table_name => 'CHAVES_ORFAS',
    key_count         => v_chaves_orfas);
  DBMS_OUTPUT.put_line('Chaves órfãs detectadas: ' || TO_CHAR(v_chaves_orfas));
END;
/

Caso existam chaves órfãs, o índice deve ser reconstruído para corrigir o problema.

Reconstrução das Freelists

Os blocos marcados como corrompidos são removidos automaticamente das freelists. Contudo, isso pode causar problemas de acesso aos blocos seguintes, sendo necessário reconstruir as freelists.

BEGIN
  DBMS_REPAIR.rebuild_freelists (
    schema_name => 'DBABRABO',
    object_name => 'CLIENTES',
    object_type => DBMS_REPAIR.table_object);
END;
/

Ignorar Blocos Corrompidos

Para garantir que os blocos corrompidos sejam ignorados durante operações de DML, utilize a rotina SKIP_CORRUPT_BLOCKS.

BEGIN
  DBMS_REPAIR.skip_corrupt_blocks (
    schema_name => 'DBABRABO',
    object_name => 'CLIENTES',
    object_type => DBMS_REPAIR.table_object,
    flags       => DBMS_REPAIR.skip_flag);
END;
/

BONUS- BBED (Para você brincar no seu LAB[APENAS])

                             ______
                          .-"      "-.
                         /            \
             _          |              |          _
            ( \         |,  .-.  .-.  ,|         / )
             > "=._     | )(__/  \__)( |     _.=" <
            (_/"=._"=._ |/     /\     \| _.="_.="\_)
                   "=._ (_     ^^     _)"_.="
                       "=\__|IIIIII|__/="
                      _.="| \IIIIII/ |"=._
            _     _.="_.="\          /"=._"=._     _
           ( \_.="_.="     `--------`     "=._"=._/ )
            > _.="                            "=._ <
           (_/                                    \_)

O utilitário BBED (Block Browser and Editor) é uma ferramenta interna do Oracle que permite visualizar e modificar blocos de dados em nível físico. No entanto, a Oracle não suporta oficialmente o BBED para uso em produção, pois ele pode ser muito perigoso se utilizado incorretamente, uma vez que permite a modificação de blocos no nível mais baixo, o que pode corromper dados se usado de maneira imprudente.

Dito isso, aqui está uma visão geral e exemplos de como você pode usar o BBED para recuperação de blocos corrompidos em Oracle. O BBED não é distribuído por padrão, mas pode ser construído a partir do Oracle Binary. Vou incluir os passos para configurá-lo e alguns exemplos de uso.

1. Preparando o BBED:

1. Verifique se o BBED está disponível no seu ambiente Oracle. Muitas vezes ele é desabilitado, mas você pode ativá-lo se encontrar o binário.

• O executável BBED geralmente pode ser encontrado em $ORACLE_HOME/rdbms/admin/bbed.par e $ORACLE_HOME/rdbms/admin/bbedus.msb.

1. Copiar e compilar o BBED:

• Copie o arquivo bbed para algum diretório de trabalho.
• Garanta que os arquivos bbed.par e bbedus.msb estejam no mesmo diretório do binário bbed.
• Conceda permissões de execução ao binário: chmod +x bbed

1. Crie um arquivo de parâmetros (bbed.par):
   O arquivo de parâmetros é necessário para fornecer informações sobre o tamanho do bloco, arquivo de dados, e outros detalhes. Exemplo do conteúdo do bbed.par:

   blocksize=8192
   listfile=/tmp/datafiles.lst
   mode=edit

4. Arquivo de lista (datafiles.lst):
   Crie um arquivo de lista de datafiles que deseja abrir com o BBED.

   /path/to/datafile1.dbf
   /path/to/datafile2.dbf

Agora o BBED está configurado e pronto para ser usado.

2. Comandos básicos de BBED:

Vamos a alguns exemplos de comandos básicos para recuperação de blocos.

2.1. Carregar o BBED e acessar um bloco:

1. Iniciar o BBED:

   $ bbed parfile=/path/to/bbed.par

Isso carrega o BBED e o arquivo de parâmetros especificado.

2. Abrir um bloco específico: Para navegar e visualizar um bloco específico no datafile, você precisa acessar o datafile e o número do bloco que deseja inspecionar.

   BBED> set dba 4,12345

Onde 4 é o número do datafile, e 12345 é o número do bloco.

3. Listar os dados do bloco: Após definir o DBA, você pode visualizar o conteúdo do bloco:

   BBED> map

Esse comando mostra um mapeamento geral do bloco, como o cabeçalho do bloco, as transações em andamento, e outros metadados.

4. Listar o conteúdo do bloco: Para exibir o conteúdo do bloco em formato hexadecimal, você pode usar o comando dump.

   BBED> dump

Esse comando exibe o conteúdo do bloco como uma lista de dados hexadecimais e ASCII. Você pode usar isso para analisar os dados corrompidos ou entender o estado atual do bloco.

2.2. Exemplo de recuperação de bloco corrompido:

Vamos supor que você tenha identificado que o bloco está corrompido e precise alterá-lo para recuperá-lo.

1. Identificar a corrupção:
   Ao visualizar o bloco, você pode verificar se há campos corrompidos ou inválidos. Suponhamos que o cabeçalho do bloco esteja corrompido.
2. Editar o cabeçalho do bloco: O campo do cabeçalho do bloco pode ser editado diretamente. Suponha que você precise ajustar o campo kcbh.seq (sequência do cabeçalho de bloco). Você pode ajustar isso manualmente. Primeiro, localize o deslocamento (offset) do campo kcbh.seq.

   BBED> p kcbh.seq

Isso imprime o valor atual do campo kcbh.seq. Agora, se ele estiver incorreto, você pode corrigir o valor:

   BBED> modify /x 0004 at kcbh.seq

Isso altera o valor do campo para 0004.

3. Salvar as alterações: Uma vez que você fez a modificação, você pode gravar o bloco de volta no datafile.

   BBED> sum
   BBED> write

O comando sum calcula o checksum do bloco modificado, e write grava o bloco de volta no arquivo de dados.

3. Se liga aqui Zé Ruela:

• BBED é extremamente perigoso: Uma única modificação incorreta pode corromper permanentemente os dados do seu banco de dados. Sempre faça um backup completo antes de usar esta ferramenta.
• A ferramenta não é documentada oficialmente: A Oracle não oferece suporte ao BBED, e ele deve ser usado apenas em casos extremos ou em ambientes de teste.

Embora o BBED possa ser uma ferramenta útil para análise em profundidade e modificação de blocos físicos de dados, ele deve ser usado com extremo cuidado e preferencialmente em ambientes de teste. Em produção, a Oracle oferece alternativas mais seguras e suportadas, como o RMAN e o DBMS_REPAIR, para recuperação de blocos corrompidos.

Considerações Finais

A recuperação de blocos de dados do Oracle é uma funcionalidade extremamente útil que evita downtime prolongado e a necessidade de restauração completa. Além disso, a capacidade de fazer dumps de blocos pode ser usada para análise forense, ajudando na resolução de problemas críticos de integridade de dados.

Dicas Importantes:

• Sempre mantenha backups atualizados.
• Verifique periodicamente se há corrupção de blocos, utilizando ferramentas como DBVERIFY e RMAN.
• Sempre utilize procedimentos e padrões com base na documentação, consulte o suporte.
• Teste e pratique cenários extremos para saber como contornar crises.
• Automatize a verificação e recuperação de blocos corrompidos com RMAN para minimizar o tempo de inatividade.

Em muitos ambientes Oracle, convivem dois mecanismos de agendamento: o DBMS_SCHEDULER (moderno) e o DBMS_JOB (legado). Cada um possui comandos, dicionários e semânticas próprios — “enabled" de um lado, “broken” do outro; DBA_SCHEDULER_* aqui, DBA_JOBS* ali; STOP_JOB vs. “matar sessão” etc.
O resultado, no dia a dia, é fricção operacional: consultas diferentes para a mesma pergunta, scripts paralelos para operações equivalentes, e uma curva de aprendizado desnecessária para tarefas simples como ver quem está rodando, habilitar/desabilitar e pausar um lote de jobs para uma janela de manutenção.

Esta solução nasce exatamente desse cenário. O objetivo é oferecer um ponto único e transparente para inventariar, monitorar e operar ambos os mecanismos sem complexidade.
Você passa a consultar uma visão consolidada (inventário e execução), e a executar um pacote único para ações comuns — seja um job Scheduler com nome, seja um DBMS_JOB numérico.

2) O que são DBMS_SCHEDULER e DBMS_JOB

DBMS_SCHEDULER (o mecanismo moderno)

Introduzido para substituir o DBMS_JOB, o DBMS_SCHEDULER oferece uma arquitetura rica e modular:

• Jobs, Programs e Schedules separados, possibilitando reuso e governança.
• Chains (fluxos com dependências), Windows e Job Classes.
• Calendário expressivo por repeat_interval (calendar expressions).
• Parada controlada (STOP_JOB), logging detalhado, priorização e integração com Resource Manager.
• Dicionário amplo (DBA_SCHEDULER_JOBS, DBA_SCHEDULER_RUNNING_JOBS, etc.).

Em suma: mais recursos, rastreabilidade e controle fino. É o padrão recomendado para novas rotinas.

DBMS_JOB (o mecanismo legado)

O DBMS_JOB é mais simples e direto:

• Cada job tem um número (ex.: 128), um comando WHAT (PL/SQL a executar), um NEXT_DATE e um INTERVAL (string).
• A disponibilidade é representada por BROKEN = 'Y'|'N' em vez de ENABLED.
• Não possui um comando nativo para parar execução em curso; na prática, usa-se o encerramento da sessão que executa o job.
• Dicionário compacto (DBA_JOBS, DBA_JOBS_RUNNING).

Embora menos flexível, é comum que ambientes antigos ainda mantenham rotinas estáveis sob DBMS_JOB.

Vantagens de utilizar esta solução

1. Interface única e coerente

• Views consolidadas para inventário (JOB_ADMIN_ALL_JOBS[_V]) e execução (JOB_ADMIN_RUNNING[_V]) que mesclam Scheduler e DBMS_JOB.
• Colunas homogêneas: enabled sempre como TRUE/FALSE, datas e intervalos formatados nas versões “_V”.

2. Produtividade imediata

• Uma consulta responde “o que tenho?”, “quando roda?”, “quem está rodando e há quanto tempo?”.
• O operador não precisa lembrar se o job é Scheduler ou DBMS_JOB para consultar status ou executar ações.

3. Operação simples e segura

• Habilitar/Desabilitar por um único procedimento (enable_job/disable_job), passando nome (Scheduler) ou número (DBMS_JOB).
• Parada elegante: para Scheduler usa STOP_JOB(force => TRUE); para DBMS_JOB, encerra a sessão de execução antes de mudar o estado (RAC-aware).
• Lote inteligente (set_jobs_by_pattern): aplique uma ação a um conjunto por LIKE, escolhendo tipo (Scheduler/DBMS_JOB/ANY) e se deve parar os ativos.

4. Observabilidade e padronização

• Saídas de list_jobs e list_running_jobs são limpas e didáticas, integrando as duas tecnologias com o mesmo layout.
• Facilita auditorias, health-checks e relatórios operacionais com menos scripts.

5. Governança simplificada

• Role única (JOBDBMSSCHEDULERALL) e sinônimos públicos: padroniza o consumo entre times e ferramentas.
• AUTHID DEFINER: quem usa não precisa de privilégio de DBA — basta receber a role.

6. Idempotência e baixa fricção de implantação

• CREATE OR REPLACE em todos os objetos e checagens defensivas: reexecutar reinstala.
• Compatível com RAC e com execução em PDB (quando aplicável).

7. Menor risco operacional

• Mensagens claras e validações garantem que “job não encontrado” ou “nome ambíguo entre owners” sejam tratados com erros explicativos.
• Em manutenção, p_stop_running => TRUE reduz inconsistências ao pausar um lote inteiro de forma controlada.

8. Porta de entrada para modernização

• Ao dar visibilidade e controle unificado, a solução facilita migrações graduais de DBMS_JOB para DBMS_SCHEDULER, sem interrupção do dia a dia.

Faça o download do instalador pkg_job_admin no link abaixo e habilite a gestão unificada de jobs Oracle.

Administração de jobs Oracle em um só lugar: Instalação e uso do pkg_job_admin

[ORCL.oracle@furushimait_labs ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Sep 10 14:52:51 2025
Version 19.20.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.20.0.0.0

SQL> @job_admin_setup_completo.sql

═════════════════════════════════════════════════════════════════════════════════════════════
Iniciando job_admin_setup_completo.sql
═════════════════════════════════════════════════════════════════════════════════════════════
Owner atual: SYS

PL/SQL procedure successfully completed.


── 1) Criando/Atualizando Views Consolidadas …

View created.


View created.


View created.


View created.

✓ Views criadas/atualizadas com sucesso.

── 2) Criando/Atualizando Pacote (SPEC) …

Package created.

No errors.

── 3) Criando/Atualizando Pacote (BODY) …

Package body created.

No errors.
✓ Pacote criado/atualizado com sucesso.

── 4) Segurança: ROLE, Grants e Sinônimos Públicos …
Role JOBDBMSSCHEDULERALL já existente.

PL/SQL procedure successfully completed.


Grant succeeded.


Grant succeeded.


Grant succeeded.


Grant succeeded.


Grant succeeded.

Sinônimos públicos criados/atualizados.

PL/SQL procedure successfully completed.

✓ Segurança configurada (ROLE + grants + sinônimos públicos).

── 5) Auto-Validação (não intrusiva) …
Pacote PKG_JOB_ADMIN sem erros de compilação.

PL/SQL procedure successfully completed.

Views acessíveis: JOB_ADMIN_ALL_JOBS e JOB_ADMIN_RUNNING OK.

PL/SQL procedure successfully completed.


── 6) Exemplos de Uso para referência  …

-- Inventário:
BEGIN
pkg_job_admin.list_jobs;                          -- todos os jobs
pkg_job_admin.list_jobs('DEMOAPP');               -- por owner
pkg_job_admin.list_jobs(p_like => 'JOB_%');       -- por padrão (LIKE)
END
/
-- Em execução agora:
BEGIN
pkg_job_admin.list_running_jobs;                       -- tudo
pkg_job_admin.list_running_jobs('DEMOAPP');            -- por owner
pkg_job_admin.list_running_jobs(p_like => 'SYNC_%');   -- por padrão (LIKE)
END
/
-- Operações pontuais:
-- SCHEDULER (por nome; owner opcional se único no banco)
-- BEGIN
--   pkg_job_admin.disable_job('DEMOAPP.JOB_ATUALIZA_INDICES', p_stop_running => TRUE)
--   pkg_job_admin.enable_job ('DEMOAPP.JOB_ATUALIZA_INDICES')
-- END
-- /
-- DBMS_JOB (por número; owner apenas para validar pertinência quando desejar)
-- BEGIN
--   pkg_job_admin.disable_job('128', p_owner => 'SYS', p_stop_running => TRUE)
--   pkg_job_admin.enable_job ('128', p_owner => 'SYS')
-- END
-- /
-- Lote por padrão (por tipo):
-- BEGIN
--   pkg_job_admin.set_jobs_by_pattern(
--     p_name_like    => 'JOB_SYNC_%',
--     p_enable       => FALSE,
--     p_owner        => 'DEMOAPP',
--     p_type         => pkg_job_admin.c_type_scheduler, -- SCHEDULER | DBMS_JOB | ANY
--     p_stop_running => TRUE
--   )
-- END
-- /
-- Visões consolidadas:
-- SELECT * FROM job_admin_all_jobs_v ORDER BY owner, job_type, job_name
-- SELECT * FROM job_admin_running_v  ORDER BY running_instance, job_type, job_name

═════════════════════════════════════════════════════════════════════════════════════════════
Conclusão: job_admin_setup_completo.sql executado.
Para conceder a ROLE a um usuário final, utilize:
GRANT JOBDBMSSCHEDULERALL TO nome_do_usuario
═════════════════════════════════════════════════════════════════════════════════════════════

O que o script cria

Objetos de dados (Views)

• JOB_ADMIN_ALL_JOBS — Inventário unificado (SCHEDULER + DBMS_JOB).
• JOB_ADMIN_RUNNING — Execução unificada no momento (SCHEDULER + DBMS_JOB).
• JOB_ADMIN_ALL_JOBS_V — Versão “amigável” do inventário (datas e intervalos formatados).
• JOB_ADMIN_RUNNING_V — Versão “amigável” da execução (intervalos formatados).

API (Package)

• PKG_JOB_ADMIN — Procedimentos para listar, habilitar/desabilitar e controlar lotes.
  • list_jobs(p_owner, p_like)
  • list_running_jobs(p_owner, p_like)
  • set_job_enabled(p_job_identifier, p_enable, p_owner, p_stop_running)
  • enable_job(...) / disable_job(...)
  • set_jobs_by_pattern(p_name_like, p_enable, p_owner, p_type, p_stop_running)
  • Constantes: c_type_scheduler, c_type_dbms_job, c_type_any

Inventário consolidado, pronto para relatório

SELECT 
  owner, 
  job_type, 
  job_name, 
  enabled, 
  state, 
  next_run_date 
FROM 
  job_admin_all_jobs_v 
ORDER BY 
  owner, 
  job_type, 
  job_name;

Execução no momento (quem está rodando agora)

SELECT 
  owner, 
  job_type, 
  job_name, 
  running_instance, 
  elapsed_time 
FROM 
  job_admin_running_v 
ORDER BY 
  running_instance, 
  job_type, 
  job_name;

Habilitar/Desabilitar individualmente

-- DBMS_SCHEDULER por nome (com owner)
BEGIN
  pkg_job_admin.disable_job('DEMOAPP.JOB_XPTO_ETL_DIARIO', p_stop_running => TRUE);
  pkg_job_admin.enable_job ('DEMOAPP.JOB_XPTO_ETL_DIARIO');
END;
/


-- DBMS_JOB por número (com validação de owner opcional)
BEGIN
  pkg_job_admin.disable_job('128', p_owner => 'SYS', p_stop_running => TRUE);
  pkg_job_admin.enable_job ('128', p_owner => 'SYS');
END;
/

Habilitar/Desabilitar JOBS em lote

BEGIN
  pkg_job_admin.set_jobs_by_pattern(
    p_name_like    => 'JOB_XPTO_%',
    p_enable       => FALSE,                            -- desativar todos que casem com o padrão
    p_owner        => 'DEMOAPP',                        -- opcional
    p_type         => pkg_job_admin.c_type_scheduler,   -- QUALQUER TIPO : SCHEDULER | DBMS_JOB | ANY
    p_stop_running => TRUE
  );
END;
/

Quais jobs existem e quando rodarão?

SELECT owner, job_type, job_name, enabled, state, next_run_date 
FROM   job_admin_all_jobs_v
ORDER  BY owner, job_type, job_name;


--  O que observar
--    • job_type: distingue SCHEDULER vs DBMS_JOB.
--    • enabled: “TRUE/FALSE” consolidado para ambos.
--    • state: útil para SCHEDULER (ex.: SCHEDULED, DISABLED).

Quais jobs contêm a palavra ‘XPTO’ no nome ou no comando?

SELECT owner, job_type, job_name, enabled, job_action
FROM   job_admin_all_jobs
WHERE  UPPER(job_name)   LIKE '%XPTO%'
   OR  UPPER(job_action) LIKE '%XPTO%'
ORDER  BY owner, job_name;

Qual o próximo agendamento dos jobs do meu schema de aplicação?

SELECT job_name, enabled, state, next_run_date
FROM   job_admin_all_jobs_v
WHERE  owner = 'DEMOAPP'
ORDER  BY job_name;

Quem está rodando agora e há quanto tempo?

SELECT owner, job_type, job_name, running_instance, elapsed_time
FROM   job_admin_running_v
ORDER  BY running_instance, job_type, job_name;

Agora vamos ver se o job JOB_XPTO_ETL_DIARIO está rodando e há quanto tempo

SELECT owner, job_type, job_name, elapsed_time
FROM   job_admin_running_v
WHERE  job_name = 'JOB_XPTO_ETL_DIARIO';

-- • Se vier linha, o job está ativo; elapsed_time mostra a duração no formato DD HH:MI:SS.

Quais jobs estão desabilitados, para uma revisão rápida?

SELECT owner, job_type, job_name, enabled
FROM   job_admin_all_jobs_v
WHERE  enabled = 'FALSE'
ORDER  BY owner, job_type, job_name;

Como usar o Pacote (exemplos passo a passo)

Todos os exemplos assumem que você possui a role JOBDBMSSCHEDULERALL.
Use os sinônimos públicos (pkg_job_admin) — não há necessidade de prefixar com schema.

-- Inventário

BEGIN
  pkg_job_admin.list_jobs;                    -- Listar TUDO!
  pkg_job_admin.list_jobs('DEMOAPP');         -- Procurar pelo OWNER
  pkg_job_admin.list_jobs(p_like => 'JOB_%'); -- Busca por jobs cujo nome contenha o padrão informado (equivalente ao LIKE).
END;
/



--- OUTPUT : 

=== JOBS (SCHEDULER) ===
DEMOAPP.JOB_XPTO_ETL_DIARIO | enabled=TRUE | state=SCHEDULED | next=2025-09-27 01:00:00 | action=BEGIN pkg_etl.run_daily; END;
DEMOAPP.JOB_SYNC_CLIENTES   | enabled=FALSE | state=DISABLED | next=- | action=BEGIN sync_clientes(); END;

=== JOBS (DBMS_JOB) ===
DEMOAPP.128 | enabled=TRUE | next=2025-09-11 03:00:00 | what=BEGIN antiga_rotina(); END;

Execução (quem está rodando) com leitura guiada

-- Agora vamos ver se o job XPTO está rodando e há quanto tempo

BEGIN
  pkg_job_admin.list_running_jobs(p_like => 'JOB_XPTO_%');
END;
/



--- OUTPUT : 

=== RUNNING (SCHEDULER) ===
DEMOAPP.JOB_XPTO_ETL_DIARIO | sid=123 | inst=1 | elapsed=00 00:07:32 | cpu=00 00:02:10

=== RUNNING (DBMS_JOB) ===
-- (vazio, se nada estiver executando)

Operações pontuais: habilitar/desabilitar

-- DBMS_SCHEDULER por nome (owner informado — mais explícito):

BEGIN
  -- desativar e forçar parada se estiver rodando
  pkg_job_admin.disable_job('DEMOAPP.JOB_XPTO_ETL_DIARIO', p_stop_running => TRUE);
  -- reativar
  pkg_job_admin.enable_job ('DEMOAPP.JOB_XPTO_ETL_DIARIO');
END;
/



--- DBMS_JOB por número (owner opcional, útil para validar pertinência):

BEGIN
  -- desativar e forçar parada se estiver rodando
  pkg_job_admin.disable_job('128', p_owner => 'DEMOAPP', p_stop_running => TRUE);
  -- reativar
  pkg_job_admin.enable_job ('128', p_owner => 'DEMOAPP');
END;
/



-- O que acontece por trás:
--   • SCHEDULER: STOP_JOB(..., force => TRUE) (se p_stop_running=>TRUE), seguido de DISABLE/ENABLE.
--   • DBMS_JOB: encerra sessão (se ativa) e marca BROKEN (NOT p_enable).

Operações em lote: desabilitar todos os “JOB_XPTO_%” do SCHEDULER

-- Cenário: janela de manutenção requer pausar rotinas XPTO do schema de aplicação.

--- Desativar
BEGIN
  pkg_job_admin.set_jobs_by_pattern(
    p_name_like    => 'JOB_XPTO_%',
    p_enable       => FALSE,                              -- desativar
    p_owner        => 'DEMOAPP',
    p_type         => pkg_job_admin.c_type_scheduler,     
    p_stop_running => TRUE                                -- encerrar active session job
  );
END;
/



--- Reativar
BEGIN
  pkg_job_admin.set_jobs_by_pattern(
    p_name_like    => 'JOB_XPTO_%',
    p_enable       => TRUE,                               -- reativar
    p_owner        => 'DEMOAPP',
    p_type         => pkg_job_admin.c_type_scheduler
  );
END;
/

Analisar o job ‘JOB_XPTO_ETL_DIARIO’ especificamente

-- 1. Está presente? Quando roda?

SELECT *
FROM   job_admin_all_jobs_v
WHERE  owner = 'DEMOAPP' AND job_name = 'JOB_XPTO_ETL_DIARIO';


-- 2. Está executando agora? Há quanto tempo?
SELECT running_instance, elapsed_time
FROM   job_admin_running_v
WHERE  owner = 'DEMOAPP' AND job_name = 'JOB_XPTO_ETL_DIARIO';

-- 3. Pausar com segurança (parar se ativo, depois desabilitar)
BEGIN
  pkg_job_admin.disable_job('DEMOAPP.JOB_XPTO_ETL_DIARIO', p_stop_running => TRUE);
END;
/

-- 4. Reativar
BEGIN
  pkg_job_admin.enable_job('DEMOAPP.JOB_XPTO_ETL_DIARIO');
END;
/

Qual a serventia dessa solução ?

Ambientes Oracle costumam conviver com dois mecanismos de agendamento: DBMS_SCHEDULER (moderno) e DBMS_JOB (legado). Quando precisamos inventariar, monitorar, habilitar/desabilitar ou gerenciar em lote ambos os tipos, a experiência comum é assimétrica e dispersa.
Este projeto entrega uma interface única e consistente para manipular os dois mundos:

• Visões consolidadas para inventário e execução.
• Um pacote PL/SQL com comandos simples e legíveis para operações pontuais e em lote.
• Role e sinônimos públicos para padronizar o consumo de forma segura.

Abaixo consta o codigo inteiro do pacote pkg_job_admin

-- =================================================================================================
--  job_admin_setup_completo.sql
--  Administração unificada de jobs no Oracle Database (DBMS_SCHEDULER e DBMS_JOB)
--  Autor: Carlos Furushima — Furushima IT
--  Direitos Autorais: Este script é propriedade intelectual de Furushima IT. Todos os direitos reservados.
--
--  OBJETIVO
--  --------
--  Fornecer uma interface única, consistente e profissional para:
--    • Inventariar jobs do SCHEDULER e do DBMS_JOB em visões consolidadas;
--    • Consultar jobs em execução (tempo decorrido e sessão, quando aplicável);
--    • Habilitar/Desabilitar jobs individualmente (por nome ou número);
--    • Habilitar/Desabilitar em lote por padrão de nome;
--    • Padronizar o consumo por meio de uma ROLE e sinônimos públicos.
--
--  O QUE É CRIADO
--  --------------
--    Views:
--      - JOB_ADMIN_ALL_JOBS      : inventário unificado (SCHEDULER + DBMS_JOB)
--      - JOB_ADMIN_RUNNING       : execução unificada (SCHEDULER + DBMS_JOB)
--      - JOB_ADMIN_ALL_JOBS_V    : inventário formatado para leitura humana
--      - JOB_ADMIN_RUNNING_V     : execução formatada para leitura humana
--
--    Pacote:
--      - PKG_JOB_ADMIN           : utilitários de listagem e (des)ativação unificada
--
--    Segurança e Acesso:
--      - ROLE JOBDBMSSCHEDULERALL com grants de SELECT/EXECUTE
--      - Sinônimos públicos para facilitar o uso por quem tiver a ROLE
--
--  PRÉ-REQUISITOS
--  --------------
--  • Executar com um usuário com privilégios para consultar dicionários DBA_* e GV$* e criar objetos.
--  • O pacote é AUTHID DEFINER (permissões do dono do pacote). Usuários finais só precisam da ROLE.
--
--  USO TÍPICO
--  ----------
--  -- Inventário:
--  BEGIN
--    pkg_job_admin.list_jobs;                       -- tudo
--    pkg_job_admin.list_jobs('DEMOAPP');            -- por owner
--    pkg_job_admin.list_jobs(p_like => 'JOB_%');    -- por padrão (LIKE)
--  END;
--  /
--
--  -- Executando agora:
--  BEGIN
--    pkg_job_admin.list_running_jobs;                       -- tudo
--    pkg_job_admin.list_running_jobs('DEMOAPP');            -- por owner
--    pkg_job_admin.list_running_jobs(p_like => 'SYNC_%');   -- por padrão (LIKE)
--  END;
--  /
--
--  -- Operações pontuais:
--  -- SCHEDULER (identificador por nome, owner opcional se único no banco)
--  -- BEGIN
--  --   pkg_job_admin.disable_job('DEMOAPP.JOB_ATUALIZA_INDICES', p_stop_running => TRUE);
--  --   pkg_job_admin.enable_job ('DEMOAPP.JOB_ATUALIZA_INDICES');
--  -- END;
--  -- /
--  --
--  -- DBMS_JOB (identificador numérico; owner opcional apenas para validar pertinência)
--  -- BEGIN
--  --   pkg_job_admin.disable_job('128', p_owner => 'SYS', p_stop_running => TRUE);
--  --   pkg_job_admin.enable_job ('128', p_owner => 'SYS');
--  -- END;
--  -- /
--
--  -- Lote por padrão (por tipo):
--  -- BEGIN
--  --   pkg_job_admin.set_jobs_by_pattern(
--  --     p_name_like    => 'JOB_SYNC_%',
--  --     p_enable       => FALSE,                               -- desativar
--  --     p_owner        => 'DEMOAPP',                           -- opcional
--  --     p_type         => pkg_job_admin.c_type_scheduler,      -- SCHEDULER | DBMS_JOB | ANY
--  --     p_stop_running => TRUE
--  --   );
--  -- END;
--  -- /
--
--  DICAS
--  -----
--  • O script é idempotente (CREATE OR REPLACE; checagens seguras). Pode ser executado mais de uma vez.
--  • Saída “limpa”: mensagens organizadas por PROMPT/DBMS_OUTPUT para auditoria e documentação.
-- =================================================================================================

SET FEEDBACK ON
SET SERVEROUTPUT ON SIZE UNLIMITED
SET VERIFY OFF

PROMPT
PROMPT ═════════════════════════════════════════════════════════════════════════════════════════════
PROMPT   Iniciando job_admin_setup_completo.sql
PROMPT ═════════════════════════════════════════════════════════════════════════════════════════════

-- -----------------------------------------------------------------------------------------------
-- 0) CONTEXTO — Mostra o usuário (owner) sob o qual os objetos serão criados
-- -----------------------------------------------------------------------------------------------
DECLARE
  l_user VARCHAR2(128) := USER;
BEGIN
  DBMS_OUTPUT.PUT_LINE('Owner atual: '||l_user);
END;
/

PROMPT
PROMPT ── 1) Criando/Atualizando Views Consolidadas …

-- ===============================================================================================
-- 1.1) JOB_ADMIN_ALL_JOBS
--      Consolida em uma única visão os jobs do DBMS_SCHEDULER e do DBMS_JOB.
--      Observações de tipos:
--        • next_run_date / last_start_date: TIMESTAMP WITH TIME ZONE (SCHEDULER) x DATE (DBMS_JOB)
--          -> o Oracle promove DATE para TIMESTAMP durante o UNION ALL (sem perda de funcionalidade).
--        • last_run_duration: INTERVAL no SCHEDULER; CAST de NULL para INTERVAL no DBMS_JOB.
--        • job_action / repeat_interval: normalizados para VARCHAR2 (até 4000) no DBMS_JOB.
-- ===============================================================================================
CREATE OR REPLACE VIEW job_admin_all_jobs AS
    SELECT owner,
           job_name,
           'SCHEDULER'               AS job_type,
           CASE WHEN enabled = 'TRUE' THEN 'TRUE' ELSE 'FALSE' END AS enabled,
           state,
           next_run_date,                                -- TIMESTAMP WITH TIME ZONE
           last_start_date,                              -- TIMESTAMP WITH TIME ZONE
           last_run_duration,                            -- INTERVAL DAY TO SECOND
           job_action,                                   -- VARCHAR2/CLOB (na maioria dos casos, até 4000)
           repeat_interval                               -- VARCHAR2
      FROM dba_scheduler_jobs
  UNION ALL
    SELECT schema_user                                   AS owner,
           TO_CHAR(job)                                  AS job_name,
           'DBMS_JOB'                                    AS job_type,
           CASE broken WHEN 'Y' THEN 'FALSE' ELSE 'TRUE' END AS enabled,
           CAST(NULL AS VARCHAR2(30))                    AS state,
           next_date,                                    -- DATE (promovido a TIMESTAMP no UNION)
           last_date                                     AS last_start_date, -- DATE
           CAST(NULL AS INTERVAL DAY TO SECOND)          AS last_run_duration,
           SUBSTR(what,     4000)                        AS job_action,      -- LONG -> VARCHAR2
           SUBSTR(interval, 4000)                        AS repeat_interval  -- LONG -> VARCHAR2
      FROM dba_jobs
;

-- ===============================================================================================
-- 1.2) JOB_ADMIN_RUNNING
--      Consolida os jobs em execução. Para DBMS_JOB, calcula elapsed pelo logon_time da sessão.
--      Observações:
--        • cpu_used não se aplica ao DBMS_JOB; representa-se com NULL (cast para INTERVAL).
-- ===============================================================================================
CREATE OR REPLACE VIEW job_admin_running AS
    SELECT owner,
           job_name,
           'SCHEDULER'               AS job_type,
           session_id,
           running_instance,
           elapsed_time,                                 -- INTERVAL
           cpu_used                                      -- INTERVAL
      FROM dba_scheduler_running_jobs
  UNION ALL
    SELECT j.schema_user           AS owner,
           TO_CHAR(r.job)          AS job_name,
           'DBMS_JOB'              AS job_type,
           r.sid                   AS session_id,
           s.inst_id               AS running_instance,
           NUMTODSINTERVAL(TRUNC((SYSDATE - s.logon_time)*86400),'SECOND') AS elapsed_time,
           CAST(NULL AS INTERVAL DAY TO SECOND)          AS cpu_used
      FROM dba_jobs_running r
      JOIN gv$session s ON s.sid = r.sid
      JOIN dba_jobs j   ON j.job = r.job
;

-- ===============================================================================================
-- 1.3) JOB_ADMIN_ALL_JOBS_V — Versão “amigável” (formatos para leitura humana)
-- ===============================================================================================
CREATE OR REPLACE VIEW job_admin_all_jobs_v AS
SELECT owner, job_name, job_type, enabled, state,
       TO_CHAR(next_run_date,'YYYY-MM-DD HH24:MI:SS')      AS next_run_date,
       TO_CHAR(last_start_date,'YYYY-MM-DD HH24:MI:SS')    AS last_start_date,
       CASE WHEN last_run_duration IS NULL THEN '-' ELSE
         EXTRACT(DAY FROM last_run_duration)||' '||
         LPAD(EXTRACT(HOUR FROM last_run_duration),2,'0')||':'||
         LPAD(EXTRACT(MINUTE FROM last_run_duration),2,'0')||':'||
         LPAD(TRUNC(EXTRACT(SECOND FROM last_run_duration)),2,'0')
       END AS last_run_duration,
       job_action, repeat_interval
  FROM job_admin_all_jobs
;

-- ===============================================================================================
-- 1.4) JOB_ADMIN_RUNNING_V — Versão “amigável” (formatos para leitura humana)
-- ===============================================================================================
CREATE OR REPLACE VIEW job_admin_running_v AS
SELECT owner, job_name, job_type, session_id, running_instance,
       CASE WHEN elapsed_time IS NULL THEN '-' ELSE
         EXTRACT(DAY FROM elapsed_time)||' '||
         LPAD(EXTRACT(HOUR FROM elapsed_time),2,'0')||':'||
         LPAD(EXTRACT(MINUTE FROM elapsed_time),2,'0')||':'||
         LPAD(TRUNC(EXTRACT(SECOND FROM elapsed_time)),2,'0')
       END AS elapsed_time,
       CASE WHEN cpu_used IS NULL THEN '-' ELSE
         EXTRACT(DAY FROM cpu_used)||' '||
         LPAD(EXTRACT(HOUR FROM cpu_used),2,'0')||':'||
         LPAD(EXTRACT(MINUTE FROM cpu_used),2,'0')||':'||
         LPAD(TRUNC(EXTRACT(SECOND FROM cpu_used)),2,'0')
       END AS cpu_used
  FROM job_admin_running
;

PROMPT ✓ Views criadas/atualizadas com sucesso.

PROMPT
PROMPT ── 2) Criando/Atualizando Pacote (SPEC) …

-- =================================================================================================
-- 2) ESPECIFICAÇÃO DO PACOTE — PKG_JOB_ADMIN
--    Contém constantes de tipo e procedimentos públicos de listagem e (des)ativação unificada.
-- =================================================================================================
CREATE OR REPLACE PACKAGE pkg_job_admin AUTHID DEFINER AS
  -- Constantes para filtro por tipo
  c_type_scheduler CONSTANT VARCHAR2(11) := 'SCHEDULER';
  c_type_dbms_job  CONSTANT VARCHAR2(8)  := 'DBMS_JOB';
  c_type_any       CONSTANT VARCHAR2(3)  := 'ANY';

  -- Listagem de jobs (inventário)
  PROCEDURE list_jobs(
    p_owner IN VARCHAR2 DEFAULT NULL,   -- filtra por owner
    p_like  IN VARCHAR2 DEFAULT NULL    -- filtra por padrão (LIKE)
  );

  -- Listagem de jobs em execução
  PROCEDURE list_running_jobs(
    p_owner IN VARCHAR2 DEFAULT NULL,   -- filtra por owner
    p_like  IN VARCHAR2 DEFAULT NULL    -- filtra por padrão (LIKE)
  );

  -- Habilita/Desabilita um job (identificador por nome SCHEDULER ou número DBMS_JOB)
  PROCEDURE set_job_enabled(
    p_job_identifier IN VARCHAR2,       -- 'OWNER.JOB_NAME' | 'JOB_NAME' | '123' (DBMS_JOB)
    p_enable         IN BOOLEAN,        -- TRUE = ENABLE; FALSE = DISABLE
    p_owner          IN VARCHAR2 DEFAULT NULL,  -- para SCHEDULER sem owner único ou DBMS_JOB para validar owner
    p_stop_running   IN BOOLEAN DEFAULT FALSE   -- encerra execução corrente (se houver)
  );

  -- Açúcares sintáticos (conveniências)
  PROCEDURE enable_job(
    p_job_identifier IN VARCHAR2,
    p_owner          IN VARCHAR2 DEFAULT NULL,
    p_stop_running   IN BOOLEAN DEFAULT FALSE
  );

  PROCEDURE disable_job(
    p_job_identifier IN VARCHAR2,
    p_owner          IN VARCHAR2 DEFAULT NULL,
    p_stop_running   IN BOOLEAN DEFAULT TRUE
  );

  -- Habilita/Desabilita em lote por padrão de nome e tipo
  PROCEDURE set_jobs_by_pattern(
    p_name_like     IN VARCHAR2,                      -- ex: 'JOB_SYNC_%'
    p_enable        IN BOOLEAN,                       -- TRUE/FALSE
    p_owner         IN VARCHAR2 DEFAULT NULL,         -- opcional
    p_type          IN VARCHAR2 DEFAULT c_type_any,   -- SCHEDULER | DBMS_JOB | ANY
    p_stop_running  IN BOOLEAN DEFAULT FALSE
  );
END pkg_job_admin;
/
SHOW ERRORS

PROMPT
PROMPT ── 3) Criando/Atualizando Pacote (BODY) …

-- =================================================================================================
-- 3) CORPO DO PACOTE — PKG_JOB_ADMIN
--    Implementa utilitários de formatação, detecção de owner/instância, e operações de controle.
-- =================================================================================================
CREATE OR REPLACE PACKAGE BODY pkg_job_admin AS

  -- ---------------------------------------------------------------------------------------------
  -- Função auxiliar: formata INTERVAL DAY TO SECOND em 'DD HH24:MI:SS'
  -- ---------------------------------------------------------------------------------------------
  FUNCTION fmt_ds(p INTERVAL DAY TO SECOND) RETURN VARCHAR2 IS
    l_day  PLS_INTEGER; l_hour PLS_INTEGER; l_min PLS_INTEGER; l_sec PLS_INTEGER;
  BEGIN
    IF p IS NULL THEN RETURN '-'; END IF;
    l_day  := EXTRACT(DAY    FROM p);
    l_hour := EXTRACT(HOUR   FROM p);
    l_min  := EXTRACT(MINUTE FROM p);
    l_sec  := TRUNC(EXTRACT(SECOND FROM p));
    RETURN LPAD(l_day,2,'0')||' '||LPAD(l_hour,2,'0')||':'||LPAD(l_min,2,'0')||':'||LPAD(l_sec,2,'0');
  END fmt_ds;

  -- ---------------------------------------------------------------------------------------------
  -- Função auxiliar: TO_CHAR seguro para datas que podem ser NULL (retorna '-' no NULL)
  -- ---------------------------------------------------------------------------------------------
  FUNCTION to_char_nvl(p_date DATE) RETURN VARCHAR2 IS
  BEGIN
    RETURN CASE WHEN p_date IS NULL THEN '-' ELSE TO_CHAR(p_date,'YYYY-MM-DD HH24:MI:SS') END;
  END;

  -- ---------------------------------------------------------------------------------------------
  -- Monta o nome totalmente qualificado do job de SCHEDULER
  -- ---------------------------------------------------------------------------------------------
  FUNCTION sched_job_fqname(p_owner IN VARCHAR2, p_job_name IN VARCHAR2) RETURN VARCHAR2 IS
  BEGIN
    RETURN CASE WHEN p_owner IS NOT NULL THEN UPPER(p_owner)||'.'||UPPER(p_job_name) ELSE UPPER(p_job_name) END;
  END;

  -- ---------------------------------------------------------------------------------------------
  -- Solicita parada de job SCHEDULER, se estiver em execução (silencioso em falhas)
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE stop_scheduler_if_running(p_owner IN VARCHAR2, p_job_name IN VARCHAR2) IS
    l_fq VARCHAR2(261) := sched_job_fqname(p_owner, p_job_name);
  BEGIN
    DBMS_SCHEDULER.STOP_JOB(job_name => l_fq, force => TRUE);
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;

  -- ---------------------------------------------------------------------------------------------
  -- Encerra sessão de DBMS_JOB, se houver (suporte RAC com @inst_id)
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE kill_dbms_job_session(p_job_id IN NUMBER) IS
    l_sid     NUMBER;
    l_serial  NUMBER;
    l_inst    NUMBER;
    l_stmt    VARCHAR2(200);
  BEGIN
    SELECT s.sid, s.serial#, s.inst_id
      INTO l_sid, l_serial, l_inst
      FROM dba_jobs_running r
      JOIN gv$session s ON s.sid = r.sid
     WHERE r.job = p_job_id
       AND ROWNUM = 1;

    l_stmt := 'ALTER SYSTEM KILL SESSION '''||l_sid||','||l_serial||
              CASE WHEN l_inst IS NOT NULL THEN ',@'||l_inst ELSE NULL END||''' IMMEDIATE';
    EXECUTE IMMEDIATE l_stmt;
  EXCEPTION
    WHEN NO_DATA_FOUND THEN NULL;
    WHEN OTHERS THEN NULL;
  END;

  -- ---------------------------------------------------------------------------------------------
  -- Resolve owner de job SCHEDULER quando usuário não informou p_owner
  -- Lança erro se não encontrado ou se existir em múltiplos owners.
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE resolve_scheduler(p_owner IN VARCHAR2, p_job_name IN VARCHAR2,
                              o_owner OUT VARCHAR2, o_job_name OUT VARCHAR2) IS
    l_cnt INTEGER;
  BEGIN
    o_job_name := UPPER(p_job_name);
    IF p_owner IS NOT NULL THEN o_owner := UPPER(p_owner); RETURN; END IF;

    SELECT COUNT(DISTINCT owner) INTO l_cnt
      FROM dba_scheduler_jobs
     WHERE job_name = o_job_name;

    IF l_cnt = 0 THEN
      RAISE NO_DATA_FOUND;
    ELSIF l_cnt > 1 THEN
      RAISE_APPLICATION_ERROR(-20002,
        'JOB_NAME existe em múltiplos owners. Informe p_owner. JOB_NAME='||o_job_name);
    ELSE
      SELECT owner INTO o_owner
        FROM dba_scheduler_jobs
       WHERE job_name = o_job_name
         AND ROWNUM = 1;
    END IF;
  END resolve_scheduler;

  -- ---------------------------------------------------------------------------------------------
  -- Listagem: inventário unificado
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE list_jobs(p_owner IN VARCHAR2 DEFAULT NULL, p_like IN VARCHAR2 DEFAULT NULL) IS
  BEGIN
    DBMS_OUTPUT.PUT_LINE('=== JOBS (SCHEDULER) ===');
    FOR r IN (
      SELECT owner, job_name, enabled, state, next_run_date, job_action
        FROM dba_scheduler_jobs
       WHERE (p_owner IS NULL OR owner = UPPER(p_owner))
         AND (p_like  IS NULL OR job_name LIKE UPPER(p_like))
       ORDER BY owner, job_name
    ) LOOP
      DBMS_OUTPUT.PUT_LINE(r.owner||'.'||r.job_name||
                           ' | enabled='||r.enabled||
                           ' | state='||NVL(r.state,'-')||
                           ' | next='||to_char_nvl(CAST(r.next_run_date AS DATE))||
                           ' | action='||SUBSTR(r.job_action,1,60));
    END LOOP;

    DBMS_OUTPUT.PUT_LINE(CHR(10)||'=== JOBS (DBMS_JOB) ===');
    FOR r IN (
      SELECT schema_user AS owner, job AS job_id, DECODE(broken,'Y','FALSE','TRUE') AS enabled,
             next_date, what
        FROM dba_jobs
       WHERE (p_owner IS NULL OR schema_user = UPPER(p_owner))
         AND (p_like  IS NULL OR TO_CHAR(job) LIKE p_like OR UPPER(what) LIKE UPPER(p_like))
       ORDER BY schema_user, job
    ) LOOP
      DBMS_OUTPUT.PUT_LINE(r.owner||'.'||r.job_id||
                           ' | enabled='||r.enabled||
                           ' | next='||to_char_nvl(r.next_date)||
                           ' | what='||SUBSTR(r.what,1,60));
    END LOOP;
  END list_jobs;

  -- ---------------------------------------------------------------------------------------------
  -- Listagem: execução unificada
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE list_running_jobs(p_owner IN VARCHAR2 DEFAULT NULL, p_like IN VARCHAR2 DEFAULT NULL) IS
  BEGIN
    DBMS_OUTPUT.PUT_LINE('=== RUNNING (SCHEDULER) ===');
    FOR r IN (
      SELECT owner, job_name, session_id, running_instance, elapsed_time, cpu_used
        FROM dba_scheduler_running_jobs
       WHERE (p_owner IS NULL OR owner = UPPER(p_owner))
         AND (p_like  IS NULL OR job_name LIKE UPPER(p_like))
       ORDER BY running_instance, job_name
    ) LOOP
      DBMS_OUTPUT.PUT_LINE(r.owner||'.'||r.job_name||
                           ' | sid='||r.session_id||
                           ' | inst='||r.running_instance||
                           ' | elapsed='||fmt_ds(r.elapsed_time)||
                           ' | cpu='||fmt_ds(r.cpu_used));
    END LOOP;

    DBMS_OUTPUT.PUT_LINE(CHR(10)||'=== RUNNING (DBMS_JOB) ===');
    FOR r IN (
      SELECT j.schema_user AS owner, r.job AS job_id, s.sid, s.serial#,
             s.inst_id AS running_instance,
             NUMTODSINTERVAL(TRUNC((SYSDATE - s.logon_time)*86400),'SECOND') AS elapsed_time,
             j.what
        FROM dba_jobs_running r
        JOIN gv$session s ON s.sid = r.sid
        JOIN dba_jobs j   ON j.job = r.job
       WHERE (p_owner IS NULL OR j.schema_user = UPPER(p_owner))
         AND (p_like  IS NULL OR TO_CHAR(r.job) LIKE p_like OR UPPER(j.what) LIKE UPPER(p_like))
       ORDER BY running_instance, job_id
    ) LOOP
      DBMS_OUTPUT.PUT_LINE(r.owner||'.'||r.job_id||
                           ' | sid='||r.sid||','||r.serial#||
                           ' | inst='||r.running_instance||
                           ' | elapsed='||fmt_ds(r.elapsed_time));
    END LOOP;
  END list_running_jobs;

  -- ---------------------------------------------------------------------------------------------
  -- Núcleo: habilita/desabilita por identificador (nome SCHEDULER ou número DBMS_JOB)
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE set_job_enabled(
    p_job_identifier IN VARCHAR2,
    p_enable         IN BOOLEAN,
    p_owner          IN VARCHAR2 DEFAULT NULL,
    p_stop_running   IN BOOLEAN DEFAULT FALSE
  ) IS
    l_owner    VARCHAR2(128);
    l_job_name VARCHAR2(128);
    l_job_id   NUMBER;
  BEGIN
    -- 1) Tentar SCHEDULER (nome)
    BEGIN
      IF REGEXP_LIKE(p_job_identifier,'^\d+$') THEN RAISE NO_DATA_FOUND; END IF;

      IF INSTR(p_job_identifier,'.') > 0 THEN
        l_owner    := UPPER(REGEXP_SUBSTR(p_job_identifier,'^([^\.]+)'));
        l_job_name := UPPER(REGEXP_SUBSTR(p_job_identifier,'\.([^\.]+)$',1,1,NULL,1));
      ELSE
        l_job_name := UPPER(p_job_identifier);
        resolve_scheduler(p_owner, l_job_name, l_owner, l_job_name);
      END IF;

      -- valida existência
      DECLARE l_dummy PLS_INTEGER;
      BEGIN
        SELECT 1 INTO l_dummy
          FROM dba_scheduler_jobs
         WHERE owner = l_owner AND job_name = l_job_name AND ROWNUM = 1;
      END;

      IF p_stop_running THEN
        stop_scheduler_if_running(l_owner, l_job_name);
      END IF;

      IF p_enable THEN
        DBMS_SCHEDULER.ENABLE( sched_job_fqname(l_owner, l_job_name) );
      ELSE
        DBMS_SCHEDULER.DISABLE( sched_job_fqname(l_owner, l_job_name) );
      END IF;

      DBMS_OUTPUT.PUT_LINE('OK (SCHEDULER) '||
        sched_job_fqname(l_owner,l_job_name)||' => '||
        CASE WHEN p_enable THEN 'ENABLED' ELSE 'DISABLED' END);

      RETURN;
    EXCEPTION
      WHEN NO_DATA_FOUND THEN NULL; -- não era scheduler; tentar DBMS_JOB
    END;

    -- 2) Tentar DBMS_JOB (número)
    BEGIN
      l_job_id := TO_NUMBER(TRIM(p_job_identifier));

      -- valida existência (restringe owner se informado)
      DECLARE l_dummy2 PLS_INTEGER;
      BEGIN
        SELECT 1 INTO l_dummy2
          FROM dba_jobs
         WHERE job = l_job_id
           AND (p_owner IS NULL OR schema_user = UPPER(p_owner))
           AND ROWNUM = 1;
      END;

      IF p_stop_running THEN
        kill_dbms_job_session(l_job_id);
      END IF;

      DBMS_JOB.BROKEN(l_job_id, NOT p_enable);

      DBMS_OUTPUT.PUT_LINE('OK (DBMS_JOB) '||l_job_id||' => '||
        CASE WHEN p_enable THEN 'ENABLED' ELSE 'DISABLED' END);

      RETURN;
    EXCEPTION
      WHEN VALUE_ERROR    THEN NULL;
      WHEN INVALID_NUMBER THEN NULL;
      WHEN NO_DATA_FOUND  THEN NULL;
    END;

    -- 3) Não encontrado em nenhuma modalidade
    RAISE_APPLICATION_ERROR(-20001,
      'Job não encontrado como SCHEDULER (por nome) nem DBMS_JOB (por número): '||p_job_identifier);
  END set_job_enabled;

  -- Açúcares sintáticos
  PROCEDURE enable_job(
    p_job_identifier IN VARCHAR2,
    p_owner          IN VARCHAR2 DEFAULT NULL,
    p_stop_running   IN BOOLEAN  DEFAULT FALSE
  ) IS
  BEGIN
    set_job_enabled(p_job_identifier => p_job_identifier,
                    p_enable         => TRUE,
                    p_owner          => p_owner,
                    p_stop_running   => p_stop_running);
  END;

  PROCEDURE disable_job(
    p_job_identifier IN VARCHAR2,
    p_owner          IN VARCHAR2 DEFAULT NULL,
    p_stop_running   IN BOOLEAN  DEFAULT TRUE
  ) IS
  BEGIN
    set_job_enabled(p_job_identifier => p_job_identifier,
                    p_enable         => FALSE,
                    p_owner          => p_owner,
                    p_stop_running   => p_stop_running);
  END;

  -- ---------------------------------------------------------------------------------------------
  -- Habilita/Desabilita em lote por padrão (LIKE) e, opcionalmente, por tipo
  -- ---------------------------------------------------------------------------------------------
  PROCEDURE set_jobs_by_pattern(
    p_name_like     IN VARCHAR2,
    p_enable        IN BOOLEAN,
    p_owner         IN VARCHAR2 DEFAULT NULL,
    p_type          IN VARCHAR2 DEFAULT c_type_any,
    p_stop_running  IN BOOLEAN  DEFAULT FALSE
  ) IS
  BEGIN
    -- SCHEDULER
    IF UPPER(p_type) IN (c_type_any, c_type_scheduler) THEN
      FOR r IN (
        SELECT owner, job_name
          FROM dba_scheduler_jobs
         WHERE (p_owner IS NULL OR owner = UPPER(p_owner))
           AND job_name LIKE UPPER(p_name_like)
      ) LOOP
        set_job_enabled(r.owner||'.'||r.job_name, p_enable, NULL, p_stop_running);
      END LOOP;
    END IF;

    -- DBMS_JOB
    IF UPPER(p_type) IN (c_type_any, c_type_dbms_job) THEN
      FOR r IN (
        SELECT schema_user AS owner, job
          FROM dba_jobs
         WHERE (p_owner IS NULL OR schema_user = UPPER(p_owner))
           AND (TO_CHAR(job) LIKE p_name_like OR UPPER(what) LIKE UPPER(p_name_like))
      ) LOOP
        set_job_enabled(TO_CHAR(r.job), p_enable, r.owner, p_stop_running);
      END LOOP;
    END IF;
  END set_jobs_by_pattern;

END pkg_job_admin;
/
SHOW ERRORS

PROMPT ✓ Pacote criado/atualizado com sucesso.

PROMPT
PROMPT ── 4) Segurança: ROLE, Grants e Sinônimos Públicos …

-- =================================================================================================
-- 4.1) ROLE — criada apenas se não existir
-- =================================================================================================
DECLARE
  l_cnt INTEGER;
BEGIN
  SELECT COUNT(*) INTO l_cnt FROM dba_roles WHERE role = 'JOBDBMSSCHEDULERALL';
  IF l_cnt = 0 THEN
    EXECUTE IMMEDIATE 'CREATE ROLE JOBDBMSSCHEDULERALL';
    DBMS_OUTPUT.PUT_LINE('Role JOBDBMSSCHEDULERALL criada.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Role JOBDBMSSCHEDULERALL já existente.');
  END IF;
END;
/

-- =================================================================================================
-- 4.2) GRANTS — executar o pacote e consultar as views por meio da ROLE
-- =================================================================================================
GRANT EXECUTE ON pkg_job_admin        TO JOBDBMSSCHEDULERALL;
GRANT SELECT  ON job_admin_all_jobs   TO JOBDBMSSCHEDULERALL;
GRANT SELECT  ON job_admin_running    TO JOBDBMSSCHEDULERALL;
GRANT SELECT  ON job_admin_all_jobs_v TO JOBDBMSSCHEDULERALL;
GRANT SELECT  ON job_admin_running_v  TO JOBDBMSSCHEDULERALL;

-- =================================================================================================
-- 4.3) SINÔNIMOS PÚBLICOS — apontam para os objetos do OWNER atual
--     Observação: garantem uso uniforme via “public synonyms” para quem tiver a ROLE.
-- =================================================================================================
DECLARE
  l_owner VARCHAR2(128) := USER;
BEGIN
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PUBLIC SYNONYM job_admin_all_jobs   FOR '||l_owner||'.job_admin_all_jobs';
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PUBLIC SYNONYM job_admin_running    FOR '||l_owner||'.job_admin_running';
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PUBLIC SYNONYM job_admin_all_jobs_v FOR '||l_owner||'.job_admin_all_jobs_v';
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PUBLIC SYNONYM job_admin_running_v  FOR '||l_owner||'.job_admin_running_v';
  EXECUTE IMMEDIATE 'CREATE OR REPLACE PUBLIC SYNONYM pkg_job_admin        FOR '||l_owner||'.pkg_job_admin';
  DBMS_OUTPUT.PUT_LINE('Sinônimos públicos criados/atualizados.');
END;
/

PROMPT ✓ Segurança configurada (ROLE + grants + sinônimos públicos).

PROMPT
PROMPT ── 5) Auto-Validação (não intrusiva) …

-- =================================================================================================
-- 5.1) Verifica erros de compilação do pacote
-- =================================================================================================
DECLARE
  l_errs INTEGER;
BEGIN
  SELECT COUNT(*) INTO l_errs
    FROM user_errors
   WHERE name = 'PKG_JOB_ADMIN';

  IF l_errs = 0 THEN
    DBMS_OUTPUT.PUT_LINE('Pacote PKG_JOB_ADMIN sem erros de compilação.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('ATENÇÃO: Encontrado(s) '||l_errs||' erro(s) em PKG_JOB_ADMIN:');
    FOR r IN (
      SELECT type, name, line, position, SUBSTR(text,1,200) AS text
        FROM user_errors
       WHERE name = 'PKG_JOB_ADMIN'
       ORDER BY sequence
    ) LOOP
      DBMS_OUTPUT.PUT_LINE(r.type||' '||r.name||' @'||r.line||':'||r.position||' - '||r.text);
    END LOOP;
  END IF;
END;
/

-- =================================================================================================
-- 5.2) Validação simples de acesso às views (sanidade)
-- =================================================================================================
DECLARE
  l_all NUMBER; l_run NUMBER;
BEGIN
  SELECT COUNT(*) INTO l_all FROM job_admin_all_jobs WHERE ROWNUM <= 1;
  SELECT COUNT(*) INTO l_run FROM job_admin_running  WHERE ROWNUM <= 1;
  DBMS_OUTPUT.PUT_LINE('Views acessíveis: JOB_ADMIN_ALL_JOBS e JOB_ADMIN_RUNNING OK.');
END;
/

PROMPT
PROMPT ── 6) Exemplos de Uso (para referência; copiar/colar quando necessário) …

PROMPT
PROMPT -- Inventário:
PROMPT BEGIN
PROMPT   pkg_job_admin.list_jobs;                          -- todos os jobs
PROMPT   pkg_job_admin.list_jobs('DEMOAPP');               -- por owner
PROMPT   pkg_job_admin.list_jobs(p_like => 'JOB_%');       -- por padrão (LIKE)
PROMPT END;
PROMPT /

PROMPT -- Em execução agora:
PROMPT BEGIN
PROMPT   pkg_job_admin.list_running_jobs;                       -- tudo
PROMPT   pkg_job_admin.list_running_jobs('DEMOAPP');            -- por owner
PROMPT   pkg_job_admin.list_running_jobs(p_like => 'SYNC_%');   -- por padrão (LIKE)
PROMPT END;
PROMPT /

PROMPT -- Operações pontuais:
PROMPT -- SCHEDULER (por nome; owner opcional se único no banco)
PROMPT -- BEGIN
PROMPT --   pkg_job_admin.disable_job('DEMOAPP.JOB_ATUALIZA_INDICES', p_stop_running => TRUE);
PROMPT --   pkg_job_admin.enable_job ('DEMOAPP.JOB_ATUALIZA_INDICES');
PROMPT -- END;
PROMPT -- /
PROMPT -- DBMS_JOB (por número; owner apenas para validar pertinência quando desejar)
PROMPT -- BEGIN
PROMPT --   pkg_job_admin.disable_job('128', p_owner => 'SYS', p_stop_running => TRUE);
PROMPT --   pkg_job_admin.enable_job ('128', p_owner => 'SYS');
PROMPT -- END;
PROMPT -- /

PROMPT -- Lote por padrão (por tipo):
PROMPT -- BEGIN
PROMPT --   pkg_job_admin.set_jobs_by_pattern(
PROMPT --     p_name_like    => 'JOB_SYNC_%',
PROMPT --     p_enable       => FALSE,
PROMPT --     p_owner        => 'DEMOAPP',
PROMPT --     p_type         => pkg_job_admin.c_type_scheduler, -- SCHEDULER | DBMS_JOB | ANY
PROMPT --     p_stop_running => TRUE
PROMPT --   );
PROMPT -- END;
PROMPT -- /

PROMPT -- Visões consolidadas:
PROMPT -- SELECT * FROM job_admin_all_jobs_v ORDER BY owner, job_type, job_name;
PROMPT -- SELECT * FROM job_admin_running_v  ORDER BY running_instance, job_type, job_name;

PROMPT
PROMPT ═════════════════════════════════════════════════════════════════════════════════════════════
PROMPT   Conclusão: job_admin_setup_completo.sql executado.
PROMPT   Para conceder a ROLE a um usuário final, utilize:
PROMPT     GRANT JOBDBMSSCHEDULERALL TO nome_do_usuario;
PROMPT ═════════════════════════════════════════════════════════════════════════════════════════════

A estrutura de armazenamento do Oracle Database é projetada para ser altamente eficiente e flexível, permitindo o armazenamento e o gerenciamento de grandes volumes de dados de forma organizada e segura.

Visão Geral da Estrutura de Armazenamento

O Oracle organiza os dados em várias camadas hierárquicas, garantindo escalabilidade e otimização. As principais estruturas de armazenamento do Oracle são:

• Database (Banco de dados)
• Tablespace
• Segment
• Extent
• Oracle Data Block

Cada um desses níveis desempenha um papel importante na organização e armazenamento dos dados.

Database

No nível mais alto da hierarquia, temos o Database. O banco de dados Oracle é composto por vários arquivos de dados que armazenam as informações do usuário e os metadados necessários para o funcionamento do sistema. Ele é o contêiner principal que engloba todos os outros componentes de armazenamento.

O Oracle Database é composto por três tipos principais de arquivos:

• Datafiles: Armazenam os dados reais.
• Redo Log Files: Guardam um histórico das alterações no banco, usados para recuperação em caso de falhas.
• Control Files: Contêm informações estruturais sobre o banco, como a localização dos datafiles e redo logs.

Tablespace

O Tablespace é o próximo nível da hierarquia e age como um contêiner lógico para organizar os dados dentro do banco de dados. Ele agrupa múltiplos datafiles, que são arquivos físicos no sistema operacional onde os dados reais são armazenados. Um banco de dados pode ter vários tablespaces, sendo cada um especializado em armazenar diferentes tipos de objetos de dados.

Os tablespaces podem ser divididos em dois tipos principais:

• Permanent Tablespaces: Armazenam dados persistentes, como tabelas e índices.
• Temporary Tablespaces: Usados para operações temporárias, como ordenações ou junções de dados durante consultas.

Exemplos comuns de tablespaces incluem:

• SYSTEM: Onde ficam os dicionários de dados (metadados do banco).
• SYSAUX: Um tablespace auxiliar para armazenar componentes não-críticos, como o AWR.
• USERS: Um tablespace típico onde são armazenados os dados dos usuários.

Segment

Dentro de cada tablespace, encontramos os segments. Um segmento é um espaço lógico alocado para armazenar um tipo específico de objeto de banco de dados, como uma tabela, índice, view materializada, rollback segment, etc.

Cada tipo de segmento desempenha um papel específico:

• Data Segments: Armazenam os dados reais das tabelas.
• Index Segments: Contêm os índices de tabelas para melhorar a performance de busca.
• Temporary Segments: Usados para operações temporárias, como ao realizar consultas grandes.
• Undo Segments: Utilizados para manter o controle das transações para garantir a consistência dos dados e permitir rollback.

Os segmentos são compostos por unidades de espaço chamadas extents.

Extent

Um extent é uma unidade contígua de espaço dentro de um segmento, onde os dados são armazenados fisicamente nos datafiles. Um segmento é composto por um ou mais extents, que são alocados conforme necessário para acomodar o crescimento do objeto de banco de dados (como uma tabela que aumenta de tamanho).

Quando um segmento precisa de mais espaço, o Oracle aloca um novo extent para ele. Os extents garantem que os dados sejam armazenados em blocos contínuos, o que melhora a eficiência de leitura/escrita.

Oracle Data Block

O nível mais baixo da hierarquia de armazenamento é o Oracle Data Block, também chamado de database block ou data block. Os data blocks representam a menor unidade de armazenamento no Oracle Database. Cada extent é composto de múltiplos data blocks.

Os data blocks armazenam os dados reais, como as linhas de uma tabela. Eles são a interface entre o banco de dados e o sistema de arquivos subjacente. O tamanho dos data blocks é configurável e pode variar (tipicamente 4KB, 8KB, 16KB ou 32KB), dependendo das necessidades do ambiente.

Os data blocks contêm várias informações, além dos dados do usuário, como cabeçalhos que registram metadados importantes, como o endereço do bloco e informações de transações.

Componentes de um Oracle Data Block

Um data block possui várias subestruturas:

1. Cabeçalho do Bloco (Block Header): Contém metadados sobre o bloco, como o endereço do bloco, identificadores de transações ativas e status de formatação.
2. Tabela de Diretório (Table Directory): Mantém informações sobre as tabelas cujos dados estão armazenados neste bloco (importante em caso de blocos com dados de mais de uma tabela).
3. Tabela de Linhas (Row Directory): Lista de ponteiros para as linhas reais armazenadas no bloco.
4. Linhas de Dados: São os dados reais das colunas de uma tabela.
5. Espaço Livre (Free Space): Espaço não utilizado no bloco que pode ser usado para inserções futuras ou expansões de linhas.
6. Gerenciamento de Espaço: O Oracle utiliza métodos sofisticados para o gerenciamento de espaço dentro dos blocos, como o PCTFREE (percentual de espaço reservado para futuras atualizações) e PCTUSED (percentual de ocupação após o qual novos dados podem ser inseridos no bloco).

Tabelas e Índices no Oracle Data Block

Os data blocks podem armazenar dados de tabelas e índices. Ao trabalhar com tabelas:

• As linhas da tabela são armazenadas dentro dos data blocks.
• Em caso de atualização, se a linha de dados crescer e não couber no bloco original, pode ocorrer a migração de linhas ou encadeamento de linhas, em que a linha é movida para outro bloco, o que pode afetar a performance.

No caso de índices, os data blocks são usados para armazenar as estruturas de árvore B-tree que organizam e aceleram a busca de dados.

No Oracle Database, a parametrização de armazenamento em uma tabela, definida pela cláusula STORAGE, determina como o espaço em disco será alocado e gerenciado para essa tabela. Esses parâmetros são essenciais para otimizar o uso de espaço, controlar o crescimento dos segmentos e reduzir a fragmentação. Eles influenciam aspectos como o tamanho dos extents, a reserva de espaço para atualizações futuras e a frequência de alocação de novos extents. Vamos explorar esses parâmetros com base na tabela de exemplo “empregados”:

CREATE TABLE empregados (
    empregado_id NUMBER PRIMARY KEY,
    nome VARCHAR2(100),
    cargo VARCHAR2(50),
    salario NUMBER(10, 2),
    data_admissao DATE DEFAULT SYSDATE,
    departamento_id NUMBER,
    CONSTRAINT fk_departamento
    FOREIGN KEY (departamento_id) REFERENCES departamentos(departamento_id)
) TABLESPACE meu_tablespace
STORAGE (
    INITIAL 64K
    NEXT 128K
    PCTINCREASE 0
)
PCTFREE 10
PCTUSED 40;

Parâmetros de Armazenamento (STORAGE Clause)

1. INITIAL

• Descrição: Define o tamanho do primeiro extent alocado para o segmento da tabela. Um extent é uma unidade contígua de espaço no disco alocada para armazenar dados.
• Exemplo: "INITIAL 64K" significa que o primeiro extent terá 64 kilobytes. Isso determina o espaço inicial reservado para a tabela ao ser criada, influenciando a capacidade inicial de armazenamento.

2. NEXT

• Descrição: Especifica o tamanho dos extents subsequentes alocados após o primeiro. À medida que a tabela cresce e o primeiro extent é preenchido, um novo extent é alocado com o tamanho definido aqui.
• Exemplo: "NEXT 128K" indica que cada novo extent alocado após o primeiro terá 128 kilobytes. Esse valor ajuda a controlar o crescimento da tabela ao longo do tempo, garantindo alocações eficientes de espaço.

3. PCTINCREASE

• Descrição: Define a porcentagem de aumento de cada novo extent em relação ao anterior. Isso controla o crescimento progressivo dos extents.
• Exemplo: "PCTINCREASE 0" indica que todos os extents subsequentes terão o mesmo tamanho definido em "NEXT", ou seja, 128K. Se fosse configurado um valor diferente de zero, cada novo extent seria maior que o anterior, aumentando pela porcentagem especificada. Por exemplo, se "PCTINCREASE" fosse 50, o próximo extent após 128K seria 192K (50% maior).

Outros Parâmetros de Tabela

1. PCTFREE

• Descrição: Determina a porcentagem de espaço em cada data block que é reservada para futuras atualizações de linhas já existentes. Isso garante que, ao alterar valores de uma linha, o bloco tenha espaço suficiente para armazenar os novos dados sem precisar movê-los para um bloco diferente.
• Exemplo: "PCTFREE 10" reserva 10% de cada data block para atualizações futuras. Se uma linha for atualizada e seus novos dados excederem o espaço previamente alocado para ela, os 10% reservados serão usados para evitar a migração de linhas para outros blocos, o que poderia impactar a performance.

2. PCTUSED

• Descrição: Define a porcentagem mínima de ocupação de um data block antes que ele seja reutilizado para novas inserções de dados. Após a exclusão ou movimentação de linhas, se o percentual de uso do bloco cair abaixo desse limite, o bloco será reutilizado para novas inserções.
• Exemplo: "PCTUSED 40" indica que, quando a ocupação do bloco cair abaixo de 40%, ele será marcado como disponível para novas inserções de dados. Esse parâmetro ajuda a evitar fragmentação e melhora a eficiência na reutilização de blocos parcialmente cheios.

Como Esses Parâmetros Funcionam Juntos

1. Alocação Inicial e Crescimento de Extents:
   • Ao criar a tabela, o Oracle aloca um extent inicial de 64K, conforme definido em "INITIAL". À medida que os dados são inseridos e o extent inicial é preenchido, o Oracle aloca novos extents de 128K, conforme especificado em "NEXT". Como "PCTINCREASE" está definido como 0, todos os extents subsequentes terão o mesmo tamanho de 128K. Isso mantém o crescimento linear e previsível da tabela.
2. Gerenciamento de Espaço Livre em Data Blocks:
   • O parâmetro "PCTFREE 10" garante que 10% de cada data block seja reservado para atualizações de dados. Isso é importante para evitar que atualizações frequentes de linhas movam os dados para novos blocos, o que reduziria a eficiência de leitura. Esse espaço reservado permite que as linhas cresçam dentro do mesmo bloco.
   • O parâmetro "PCTUSED 40" garante que blocos parcialmente utilizados sejam reutilizados para novas inserções quando sua ocupação cair abaixo de 40%. Isso ajuda a evitar o desperdício de espaço em blocos que não estão completamente cheios e reduz a necessidade de alocar novos blocos, otimizando o uso do espaço.

Benefícios da Configuração Correta dos Parâmetros de Armazenamento

Ao configurar corretamente os parâmetros de armazenamento, é possível otimizar o uso de espaço e melhorar a performance da tabela. Esses parâmetros permitem ao DBA:

• Controlar o crescimento do segmento: Ao especificar tamanhos adequados para os extents e definir políticas claras para a alocação subsequente, o crescimento da tabela é gerenciado de maneira eficiente, evitando fragmentação excessiva.
• Gerenciar atualizações e inserções: Parâmetros como "PCTFREE" e "PCTUSED" garantem que os blocos de dados sejam utilizados de forma inteligente, reservando espaço para atualizações e reutilizando blocos que ficaram abaixo da ocupação mínima.
• Prevenir fragmentação: O controle da alocação de extents e a reutilização de blocos parcialmente ocupados ajudam a minimizar a fragmentação, o que melhora a performance de leitura e escrita no banco de dados.

Esses parâmetros, quando bem configurados, são ferramentas poderosas para otimizar o armazenamento e o desempenho de tabelas no Oracle Database, garantindo uma utilização eficiente dos recursos de hardware e mantendo a performance à medida que a tabela cresce e é atualizada ao longo do tempo.

Antes que os usuários possam se conectar a uma instância de banco de dados, um administrador de banco de dados deve iniciar a instância do banco de dados. A instância e o banco de dados passam por estágios à medida que o banco de dados é disponibilizado para acesso pelos usuários. A instância é iniciada, o banco de dados é montado e, em seguida, o banco de dados é aberto, como mostrado no slide.

NOMOUNT: Nesta etapa, o software Oracle lê um arquivo de parâmetros de inicialização, PFILE ou SPFILE, inicia os processos em segundo plano, aloca memória para a SGA, abre o log de alerta e os arquivos de rastreamento. Uma instância é tipicamente iniciada apenas no modo NOMOUNT durante a criação do banco de dados, durante a recriação de arquivos de controle ou em cenários específicos de backup e recuperação.

MOUNT: Nesta etapa, o software Oracle associa o banco de dados à instância de banco de dados previamente iniciada, abre e lê o controlefile especificado no arquivo de parâmetros de inicialização, PFILE ou SPFILE, e obtém os nomes e estados dos datafiles e dos redo logs. No entanto, nesta fase, não são realizadas verificações para confirmar a existência dos datafiles e dos redo logs. Iniciar no modo MOUNT para executar algumas operações de manutenção, como renomear datafiles e realizar restore do banco de dados.

OPEN: O software Oracle abre os redo logs e os datafiles de acordo com a lista registrada no controlefile. Inicie no modo OPEN para permitir que os usuários se conectem à instância do banco de dados. Os PDBs não são iniciados por padrão quando você abre o banco de dados.

Desligando a instância do banco de dados Oracle

Às vezes, é necessário desligar a instância do banco de dados (por exemplo, para alterar um parâmetro estático ou aplicar um patch no servidor do banco de dados).

Use o comando SHUTDOWN para desligar a instância do banco de dados, porém há vários modos possívels de se desligar a instância: ABORT, IMMEDIATE, NORMAL e TRANSACTIONAL.

ABORT: Se os outros modos de desligamento não funcionarem, você pode usar o modo ABORT. O modo ABORT executa a menor quantidade de trabalho antes de desligar. Como esse modo coloca o banco de dados em um estado inconsistente e requer recuperação antes do reinício, use-o apenas quando necessário. Não é aconselhável fazer backup do banco de dados nesse estado. Geralmente, é usado quando nenhuma outra forma de desligamento funciona, quando há problemas para iniciar a instância do banco de dados ou quando você precisa desligar imediatamente devido a uma situação iminente (como aviso de queda de energia em questão de segundos). O modo ABORT costuma ser o modo de desligamento mais rápido, e o modo NORMAL é o mais lento. Os modos NORMAL e TRANSACTIONAL podem levar muito tempo, dependendo do número de sessões e transações.

Durante um desligamento no modo ABORT, uma falha na instância ou um reinício da instância do banco de dados no modo FORCE, o que acontece com o banco de dados:

• As declarações SQL atuais sendo processadas pelo servidor Oracle são imediatamente interrompidas.
• O servidor Oracle não espera pelos usuários que estão atualmente conectados ao banco de dados se desconectarem.
• Os buffers do banco de dados e de redo não são gravados em disco.
• Transações não confirmadas não são revertidas.
• A instância é terminada sem fechar os arquivos.
• O banco de dados não é fechado ou desmontado.
• O próximo reinício requer recuperação da instância, que ocorre automaticamente pelo processo SMON.

IMMEDIATE: Um desligamento no modo IMMEDIATE é a opção mais utilizada. • As declarações SQL atuais sendo processadas pela instância do banco de dados não são concluídas. • O servidor de banco de dados não espera pelos usuários que estão atualmente conectados à instância do banco de dados se desconectarem. • O servidor de banco de dados faz rollback das transações ativas e desconecta todos os usuários conectados. • O servidor de banco de dados fecha e desmonta o banco de dados antes de desligar a instância do banco de dados.

NORMAL: NORMAL é o modo de desligamento padrão se nenhum modo for especificado com o comando SHUTDOWN. • Novas conexões não podem ser feitas. • O servidor Oracle espera que todos os usuários se desconectem antes de concluir o desligamento. • Buffers de banco de dados e de redo são gravados em disco. • Processos em segundo plano são terminados e a SGA é removida da memória. • O servidor Oracle fecha e desmonta o banco de dados antes de desligar a instância.

TRANSACTIONAL: Um desligamento no modo TRANSACTIONAL impede que os clientes percam dados, incluindo resultados de sua atividade atual. • Nenhum cliente pode iniciar uma nova transação nesta instância específica. • Um cliente é desconectado quando o cliente encerra a transação que está em andamento. • Quando todas as transações forem concluídas, ocorre um desligamento imediato.

Exemplos práticos:

Executando apenas o comando STARTUP é possível verificar todas as etapas que a instância transita até o estado OPEN, onde a base de dados está aberta e pronta para receber conexões:

É possível escolher a fase de inicialização da instância utilizando as opções NOMOUNT ou MOUNT:

STARTUP NOMOUNT, o arquivo de parametros PFILE ou SPFILE será lido e apenas a instância fará a alocação na memória:

-- VERIFICAR O STATUS(FASE) DA INSTÂNCIA

SELECT STATUS FROM V$INSTANCE;

Ao consultar o status da instância, aparecerá

STARTUP MOUNT, o arquivo de parametros PFILE ou SPFILE será lido, a instância iniciará e o controlfile será montado:

Ao consultar o status da instância, aparecerá como MOUNTED:

SHUTDOWN IMMEDIATE, que é o mais utilizado, ve-se também todas as fases:

Mas o que exatamente são as views?

Uma view pode ser entendida como uma tabela virtual que se baseia no resultado de uma consulta, ou seja, ao invés de armazenar os dados diretamente ela apenas exibe os dados pertencentes a outras tabelas. Estes dados são recuperados através de uma instrucão SQL toda vez que a view é executada.

De acordo com a documentação da versão 19c do Oracle, temos:

Use the CREATE VIEW statement to define a view, which is a logical table based on one or more tables or views. A view contains no data itself. The tables upon which a view is based are called base tables.

Vantagens ao utilizar views

– Simplicar consultar complexas

A utilização de views possibilita que uma query complexa seja encapsulada em uma query simples.

– Segurança no acesso aos dados

Através da utilização de views é possível restringir o acesso a colunas ou linhas específicas, podendo assim exibir somente os dados necessários.

– Abstração

Com as views é possível implementar uma camada de abstração que permite ocultar tanto a estrutura das tabelas ou até mesmo a fonte dos dados.

– Reutilização de consulta

Para consultas que são utilizadas com certa frequência é indica a criação de views para reduzir a repetição de código.

Tipos de Views no Oracle

Views

Podem ter desde uma estrutura simplificada baseada em apenas uma tabela e sem funções de agregações e joins ou até mesmo mais complexas com joins entre multiplas tabelas, funções de agregação, subconsultas, etç.

As views com estrutura simples geralmente permitem que sejam feitas inserções e alterações nos dados da tabela de origem.

Já as views que não permitem inserções e alterações são as que possuem clasulas como DISTINCT, funções de agregação, GROPU BY, ORDER BY, sub queries no select, condições recursivas com a clásula WITH, etç.

Independente da estrutura da view, ela não ocupa espaço em disco.

Mais informações disponíveis em https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/UPDATE.html

Exemplo:

CREATE VIEW vw_empresas AS
SELECT id, nome_empresa
FROM empresas;

Materialized Views

Já as materialized views (views materializadas) armazenam os dados fisicamente, ou seja, ela irá consumir espaço em disco.

As materialized views podem ser usadas para melhorar a performance em consultas complexas ou consultas que envolvam grandes volumes de dados.

Também é possível utiliá-las para transportar ou replicar dados para outros bancos de dados oracle através de database links.

As MVs podem ser atualizadas periodicamente ou sob demanda e podem ser totalmente reconstruídas a cada atualização ou de maneira incremental com a utilização de mlogs (materialized view logs).

Exemplo:

CREATE MATERIALIZED VIEW mv_vendas
REFRESH FAST ON COMMIT
AS
SELECT produto_id, SUM(quantidade) AS total_vendido
FROM vendas
GROUP BY produto_id;