Oracle offre diversi metodi per rilevare e correggere la corruzione dei blocchi di dati. Un metodo è quello di eliminare e ricreare un oggetto dopo che il danneggiamento è stato rilevato; tuttavia, questo non è sempre possibile o desiderabile. Se la corruzione dei blocchi di dati è limitata a un sottoinsieme di righe, un’altra opzione è quella di ricostruire la tabella selezionando tutti i dati ad eccezione delle righe corrotte.
Un altro modo per gestire la corruzione dei blocchi di dati è usare il pacchetto DBMS_REPAIR. È possibile utilizzare DBMS_REPAIR per rilevare e riparare i blocchi corrotti in tabelle e indici. Utilizzando questo approccio, è possibile risolvere i danneggiamenti ove possibile e continuare a utilizzare gli oggetti mentre si tenta di ricostruirli o ripararli. DBMS_REPAIR utilizza il seguente approccio per affrontare i danneggiamenti:
- Passo 1: Individuare e Segnalare Danneggiamenti
- Passo 2: Valutare i Costi e Benefici dell’Uso di DBMS_REPAIR
- Fase 3: Fare Oggetti Utilizzabili
- Passo 4: ripristinare i Danneggiamenti e Ricostruire i Dati Persi
Nota:
Qualsiasi danneggiamento che comporta la perdita di dati richiede analisi e comprensione di come tali dati si inseriscono nel sistema di database complessivo. Quindi, DBMS_REPAIR non è una bacchetta magica: devi comunque determinare se l’approccio di riparazione fornito da questo pacchetto è lo strumento appropriato per ogni specifico problema di corruzione. A seconda della natura della riparazione, è possibile perdere dati e possono essere introdotte incongruenze logiche; pertanto è necessario valutare i guadagni e le perdite associati all’utilizzo di DBMS_REPAIR.
DBMS_REPAIR Contenuto della confezione
La tabella 19-1 descrive le procedure che compongono il pacchetto DBMS_REPAIR.
Tabella 19-1 Procedure DBMS_REPAIR
| Nome della procedura | Descrizione |
|---|---|
|
|
Rileva e segnala corruzioni in una tabella o indice. |
|
|
Contrassegna i blocchi (precedentemente identificati dalla procedura |
|
|
Riporta le voci di indice che puntano a righe in blocchi di dati corrotti. |
|
|
Ricostruisce i freelist di un oggetto. |
|
|
Quando viene utilizzato, ignora i blocchi contrassegnati corrotti durante le scansioni di tabelle e indici. Se non viene utilizzato, si ottiene l’errore ORA-1578 quando si incontrano blocchi contrassegnati corrotti. |
|
|
Fornisce funzioni amministrative (create, drop, purge) per DBMS_REPAIR repair e tabelle chiave orfane. Nota: queste tabelle vengono sempre create nello schema SYS. |
Passo 1: Rileva e segnala corruzioni
La tua prima attività, prima di utilizzare DBMS_REPAIR, dovrebbe essere il rilevamento e la segnalazione di corruzioni. La segnalazione non solo indica cosa c’è di sbagliato in un blocco, ma identifica anche la direttiva di riparazione associata. Sono disponibili diverse opzioni, oltre a DBMS_REPAIR, per rilevare le corruzioni. La tabella 19-2 descrive le diverse metodologie di rilevamento.
Tabella 19-2 Confronto dei metodi di rilevamento della corruzione
| Metodo di rilevamento | Descrizione |
|---|---|
|
_RIPARAZIONE DBM |
Esegue il controllo dei blocchi per una tabella, una partizione o un indice specificati. Popola una tabella di riparazione con i risultati. |
|
_VERIFICA DB |
Utility da riga di comando esterna che esegue il controllo dei blocchi su un database offline. |
|
ANALIZZA |
Utilizzato con l’opzione VALIDATE STRUCTURE, verifica l’integrità della struttura di un indice, una tabella o un cluster; verifica o verifica che le tabelle e gli indici siano sincronizzati. |
|
DB_BLOCK_CHECKING |
Identifica i blocchi corrotti prima che siano effettivamente contrassegnati come corrotti. I controlli vengono eseguiti quando vengono apportate modifiche a un blocco. |
DBMS_REPAIR: utilizzando le procedure check_object e admin_tables
I controlli e i report della procedura check_object bloccano i corruzioni per un oggetto specificato. Simile all’ANALISI…VALIDATE STRUCTURE statement per indici e tabelle, il controllo dei blocchi viene eseguito rispettivamente per i blocchi indice e dati.
Non solo check_object segnala corruzioni, ma identifica anche eventuali correzioni che si verificano se fix_corrupt_blocks viene successivamente eseguito sull’oggetto. Queste informazioni vengono rese disponibili compilando una tabella di riparazione, che deve prima essere creata dalla procedura admin_tables.
Dopo aver eseguito la procedura check_object , una semplice query nella tabella di riparazione mostra le direttive corruzioni e riparazione per l’oggetto. Con queste informazioni, è possibile valutare il modo migliore per affrontare i problemi segnalati.
DB_VERIFY: esecuzione di un controllo del database offline
In genere, si utilizza DB_VERIFY come utilità di diagnostica offline quando si verificano problemi di danneggiamento dei dati.
Vedi anche: Per ulteriori informazioni su DB_VERIFY, vedere Utilità Oracle8i.
ANALIZZA: segnalazione di corruzione
La TABELLA DI ANALISI…L’istruzione VALIDATE STRUCTURE convalida la struttura dell’oggetto analizzato. Se Oracle convalida correttamente la struttura, viene restituito un messaggio che conferma la sua convalida. Se Oracle rileva corruzione nella struttura dell’oggetto, viene restituito un messaggio di errore. In questo caso, si dovrebbe cadere e ricreare l’oggetto.
Vedere anche: Per ulteriori informazioni sull’istruzione ANALYZE, vedere il riferimento SQL Oracle8i.
DB_BLOCK_CHECKING (Parametro di inizializzazione del controllo dei blocchi)
È possibile impostare il controllo dei blocchi per le istanze tramite il parametro DB_BLOCK_CHECKING (il valore predefinito è TRUE); questo controlla i blocchi di dati e indice ogni volta che vengono modificati. DB_BLOCK_CHECKING è un parametro dinamico, modificabile dall’istruzione ALTER SYSTEM SET.
Fase 2: Valutare i costi e i benefici dell’utilizzo di DBMS_REPAIR
Prima di utilizzare DBMS_REPAIR è necessario valutare i benefici del suo utilizzo in relazione alle passività; dovresti anche esaminare altre opzioni disponibili per indirizzare gli oggetti corrotti.
Un primo passo è quello di rispondere alle seguenti domande:
- Qual è l’entità della corruzione?
Per determinare se ci sono corruzioni e azioni di riparazione, eseguire la procedura
check_objecte interrogare la tabella di riparazione. - Quali altre opzioni sono disponibili per affrontare le corruzioni dei blocchi?
Supponendo che i dati siano disponibili da un’altra fonte, rilasciare, ricreare e ripopolare l’oggetto. Un’altra opzione è quella di emettere la TABELLA CREATE…COME istruzione SELECT dalla tabella corrotta per crearne una nuova.
È possibile ignorare la corruzione escludendo le righe corrotte dalle istruzioni select.
Eseguire il recupero dei supporti.
- Quali corruzioni logiche o effetti collaterali verranno introdotti quando si utilizza DBMS_REPAIR per rendere utilizzabile un oggetto? Questi possono essere affrontati? Qual è lo sforzo necessario per farlo?
Potresti non avere accesso alle righe nei blocchi contrassegnati come corrotti. Tuttavia, un blocco può essere contrassegnato corrotto anche se ci sono ancora righe a cui è possibile accedere validamente.
I vincoli di integrità referenziale possono essere interrotti quando i blocchi sono contrassegnati come corrotti. Se ciò si verifica, disabilitare e riattivare il vincolo; verranno segnalate eventuali incongruenze. Dopo aver risolto tutti i problemi, dovresti essere in grado di riattivare correttamente il vincolo.
Corruzione logica può verificarsi quando ci sono trigger definiti sulla tabella. Ad esempio, se le righe vengono reinserite, i trigger insert dovrebbero essere attivati o no? È possibile risolvere questi problemi solo se si comprendono i trigger e il loro utilizzo nell’installazione.
I blocchi Freelist potrebbero essere inaccessibili. Se un blocco corrotto è alla testa o alla coda di un freelist, la gestione dello spazio reinizializza il freelist. Quindi potrebbero esserci blocchi che dovrebbero essere su un freelist, che non lo sono. Puoi risolvere questo problema eseguendo la procedura
rebuild_freelists.Indici e tabelle potrebbero non essere sincronizzati. È possibile risolvere questo problema eseguendo prima la procedura
dump_orphan_keys(per ottenere informazioni dalle chiavi che potrebbero essere utili nella ricostruzione di dati danneggiati). Quindi emettere l’istruzione ALTER INDEX REBUILD ONLINE per ripristinare la tabella e i suoi indici in sincronia. - Se la riparazione comporta la perdita di dati, è possibile recuperare questi dati?
È possibile recuperare i dati dall’indice quando un blocco di dati è contrassegnato danneggiato. Le procedure
dump_orphan_keyspossono aiutarti a recuperare queste informazioni. Naturalmente, il recupero dei dati in questo modo dipende dalla quantità di ridondanza tra gli indici e la tabella.
Passaggio 3: Rendere gli oggetti utilizzabili
In questo passaggio DBMS_REPAIR rende l’oggetto utilizzabile ignorando le corruzioni durante le scansioni di tabelle e indici.
Riparazione corruzione: Utilizzando le procedure fix_corrupt_blocks e skip_corrupt_blocks
Si rende utilizzabile un oggetto corrotto stabilendo un ambiente che ignora le corruzioni che rimangono al di fuori dell’ambito delle funzionalità di riparazione di DBMS_REPAIR.
Se le corruzioni comportano una perdita di dati, ad esempio una riga errata in un blocco di dati, tutti questi blocchi vengono contrassegnati come corrotti dalla procedura fix_corrupt_blocks. Quindi, è possibile eseguire la procedura skip_corrupt_blocks, che salterà i blocchi contrassegnati come corrotti per l’oggetto. Quando skip è impostato, le scansioni di tabelle e indici saltano tutti i blocchi contrassegnati come corrotti. Questo vale sia per i supporti che per i blocchi corrotti del software.
Implicazioni quando si saltano i blocchi corrotti
Se un indice e una tabella non sono sincronizzati, una transazione di SOLA LETTURA della TRANSAZIONE IMPOSTATA potrebbe essere incoerente in situazioni in cui una query sonde solo l’indice e quindi una query successiva sonde sia l’indice che la tabella. Se il blocco della tabella è contrassegnato come corrotto, le due query restituiranno risultati diversi, infrangendo così le regole di una transazione di sola lettura. Un modo per avvicinarsi a questo è non saltare le corruzioni quando in una TRANSAZIONE di SOLA LETTURA di UNA TRANSAZIONE IMPOSTATA.
Si verifica un problema simile quando si selezionano le righe concatenate. In sostanza, una query della stessa riga può o non può accedere alla corruzione, dando così risultati diversi.
Passaggio 4: Riparare i danni e ricostruire i dati persi
Dopo aver reso utilizzabile un oggetto, è possibile eseguire le seguenti attività di riparazione.
Recuperare i dati utilizzando le procedure dump_orphan_keys
La procedura dump_orphan_keys riporta le voci di indice che puntano a righe in blocchi di dati corrotti. Tutte queste voci dell’indice vengono inserite in una tabella chiave orfana che memorizza la chiave e il rowid del danneggiamento.
Dopo aver recuperato le informazioni sulla voce dell’indice, è possibile ricostruire l’indice utilizzando l’istruzione ALTER INDEX REBUILD ONLINE.
Riparare i Freelist utilizzando la procedura rebuild_freelists
Quando un blocco contrassegnato come “corrotto” viene trovato in testa o in coda a un freelist, il freelist viene reinizializzato e viene restituito un errore. Anche se questo toglie il blocco incriminato dal freelist, ti fa perdere l’accesso freelist a tutti i blocchi che hanno seguito il blocco corrotto.
È possibile utilizzare la procedura rebuild_freelists per reinizializzare i freelist. L’oggetto viene scansionato e, se è appropriato che un blocco sia sul freelist, viene aggiunto al master freelist. I gruppi freelist sono gestiti misurando i blocchi in modo equo – un blocco alla volta. Tutti i blocchi contrassegnati come “corrotti” nell’oggetto vengono ignorati durante la ricostruzione.
Limitazioni e restrizioni
Le procedure DBMS_REPAIR presentano le seguenti limitazioni:
- Le tabelle con LOB, tabelle nidificate e VARRAY sono supportate, ma le colonne fuori riga vengono ignorate.
- I cluster sono supportati nelle procedure
skip_corrupt_blockserebuild_freelist, ma non nella proceduracheck_object. - Le tabelle e gli indici LOB organizzati in indici non sono supportati.
- La procedura
dump_orphan_keysnon funziona su indici bitmap o indici basati su funzioni. - La procedura
dump_orphan_keyselabora chiavi lunghe al massimo 3.950 byte.
Procedure DBMS_REPAIR
Questa sezione contiene descrizioni dettagliate delle procedure DBMS_REPAIR.
check_object
La procedura check_object controlla gli oggetti specificati e popola la tabella di riparazione con informazioni su corruzioni e direttive di riparazione. La convalida consiste nel controllo del blocco di tutti i blocchi nell’oggetto. È possibile specificare facoltativamente un intervallo, un nome di partizione o un nome di sottopartizione quando si desidera controllare una porzione di un oggetto.
procedure check_object(schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN binary_integer DEFAULT NULL, relative_fno IN binary_integer DEFAULT NULL, block_start IN binary_integer DEFAULT NULL, block_end IN binary_integer DEFAULT NULL, corrupt_count OUT binary_integer)
Tabella 19-3 Il check_object Procedura
| Argomento | Descrizione |
|---|---|
|
|
Schema nome dell’oggetto da controllare. |
|
|
Nome della tabella o dell’indice da controllare. |
|
|
Nome della partizione o della sottopartizione da controllare. Se si tratta di un oggetto partizionato e |
|
|
Tipo dell’oggetto da elaborare. Deve essere TABLE_OBJECT o INDEX_OBJECT. Il valore predefinito è TABLE_OBJECT. |
|
|
Nome della tabella di riparazione da compilare. La tabella deve esistere nello schema SYS. Utilizzare la procedura |
|
|
Riservato per uso futuro. |
|
|
Numero di file relativo. Utilizzato quando si specifica un intervallo di blocchi. |
|
|
Il primo blocco da elaborare se si specifica un intervallo di blocchi. Può essere specificato solo se l’oggetto è una singola tabella, partizione o sottopartizione. |
|
|
L’ultimo blocco da elaborare se si specifica un intervallo di blocchi. Può essere specificato solo se l’oggetto è una singola tabella, partizione o sottopartizione. Se viene specificato solo uno di block_start o block_end, l’altro valore predefinito è rispettivamente il primo o l’ultimo blocco nel file. |
|
|
Il numero di corruzioni segnalate. |
fix_corrupt_blocks
Utilizzare questa procedura per correggere i blocchi corrotti negli oggetti specificati in base alle informazioni nella tabella di riparazione precedentemente generate dalla procedura check_object. Prima di effettuare qualsiasi modifica a un blocco, il blocco viene controllato per assicurarsi che il blocco sia ancora danneggiato. I blocchi corrotti vengono riparati contrassegnando il software di blocco corrotto. Quando viene eseguita una riparazione, la riga associata nella tabella di riparazione viene aggiornata con un timestamp di correzione.
procedure fix_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN boolean DEFAULT NULL, fix_count OUT binary_integer)
Tabella 19-4 La procedura fix_corrupt_blocks
| Argomento | Descrizione |
|---|---|
|
|
Nome dello schema. |
|
|
Nome dell’oggetto con blocchi corrotti da correggere. |
|
|
Nome della partizione o della sottopartizione da elaborare. Se questo è un oggetto partizionato e |
|
|
Tipo dell’oggetto da elaborare. Deve essere TABLE_OBJECT o INDEX_OBJECT. Il valore predefinito è TABLE_OBJECT. |
|
|
Nome della tabella di riparazione con le direttive di riparazione. Deve esistere nello schema SYS. |
|
|
Riservato per uso futuro. |
|
|
Il numero di blocchi fissi. |
dump_orphan_keys
Rapporti sulle voci di indice che puntano a righe in blocchi di dati corrotti. Per ciascuna voce di indice rilevata, viene inserita una riga nella tabella orfana specificata.
Se viene specificata la tabella di riparazione, tutti i blocchi corrotti associati alla tabella di base vengono gestiti in aggiunta a tutti i blocchi di dati contrassegnati come software corrotto. In caso contrario, vengono gestiti solo i blocchi contrassegnati come corrotti.
Queste informazioni possono essere utili per ricostruire le righe perse nella tabella e per scopi diagnostici.
procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', orphan_table_name IN varchar2 DEFAULT 'ORPHAN_KEY_TABLE', key_count OUT binary_integer)
Tabella 19-5 La procedura dump_orphan_keys
| Argomento | Descrizione |
|---|---|
|
|
Nome dello schema. |
|
|
Nome oggetto. |
|
|
Nome della partizione o della sottopartizione da elaborare. Se questo è un oggetto partizionato e |
|
|
Tipo dell’oggetto da elaborare. Il valore predefinito è INDEX_OBJECT. |
|
|
Nome della tabella di riparazione contenente informazioni sui blocchi corrotti nella tabella di base. La tabella specificata deve esistere nello schema SYS. La procedura |
|
|
Nome della tabella delle chiavi orfane da compilare con le informazioni relative a ciascuna voce di indice che fa riferimento a una riga in un blocco di dati danneggiato. La tabella specificata deve esistere nello schema SYS. La procedura |
|
|
Numero di voci dell’indice elaborate. |
rebuild_freelists
Ricostruisce i freelist per l’oggetto specificato. Tutti i blocchi liberi sono posizionati sul master freelist. Tutti gli altri freelist sono azzerati. Se l’oggetto ha più gruppi freelist, i blocchi liberi vengono distribuiti tra tutti i freelist, assegnando ai diversi gruppi in modo round-robin.
procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);
Tabella 19-6 La procedura rebuild_freelists
| Argomento | Descrizione |
|---|---|
|
|
Nome dello schema. |
|
|
Nome dell’oggetto i cui freelist devono essere ricostruiti. |
|
|
Nome di partizione o sottopartizione i cui freelist devono essere ricostruiti. Se questo è un oggetto partizionato e |
|
|
Tipo dell’oggetto da elaborare. Deve essere TABLE_OBJECT o INDEX_OBJECT. Il valore predefinito è TABLE_OBJECT. |
skip_corrupt_blocks
Abilita o disabilita il salto di blocchi corrotti durante la scansione di indici e tabelle dell’oggetto specificato. Quando l’oggetto è una tabella, skip si applica alla tabella e ai suoi indici. Quando l’oggetto è un cluster, si applica a tutte le tabelle del cluster e ai rispettivi indici.
procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN boolean DEFAULT SKIP_FLAG);
Tabella 19-7 Il skip_corrupt_blocks Procedura
| Argomento | Descrizione |
|---|---|
|
|
Schema nome dell’oggetto da elaborare. |
|
|
Nome dell’oggetto. |
|
|
Nome della partizione o della sottopartizione da elaborare. Se questo è un oggetto partizionato e |
|
|
Tipo dell’oggetto da elaborare. Deve essere TABLE_OBJECT o CLUSTER_OBJECT. Il valore predefinito è TABLE_OBJECT. |
|
|
Se viene specificato SKIP_FLAG, attiva il salto dei blocchi corrotti del software per l’oggetto durante le scansioni di indici e tabelle. Se viene specificato NOSKIP_FLAG, le scansioni che incontrano blocchi corrotti dal software restituiscono un ORA-1578. |
admin_tables
Fornisce funzioni amministrative per la riparazione e tabelle chiave orfane.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
Tabella 19-8 Il admin_tables Procedura
| Argomento | Descrizione |
|---|---|
|
|
Nome della tabella per l’elaborazione. Il valore predefinito è ‘ORPHAN_KEY_TABLE’ o ‘REPAIR_TABLE’ in base al tipo di tabella specificato. Quando specificato, il nome della tabella deve avere il prefisso appropriato, ‘ORPHAN_’ o ‘REPAIR_’. |
|
|
Tipo di tabella, deve essere uno di ORPHAN_TABLE o REPAIR_TABLE. |
|
|
Indica quale azione amministrativa eseguire. Deve essere CREATE_ACTION, PURGE_ACTION o DROP_ACTION. Se la tabella esiste già e viene specificato CREATE_ACTION, viene restituito un errore. PURGE_ACTION indica di eliminare tutte le righe della tabella associate a oggetti inesistenti. Se la tabella non esiste e viene specificato DROP_ACTION, viene restituito un errore. Quando vengono specificati CREATE_ACTION e DROP_ACTION, viene creata e rilasciata rispettivamente una vista associata denominata DBA_< nome_table>. La vista è definita in modo che le righe associate a oggetti inesistenti vengano eliminate. Creato nello schema SYS. |
|
|
Indica lo spazio tabella da utilizzare durante la creazione di una tabella. Per impostazione predefinita, viene utilizzato lo spazio tabella predefinito di SYS. Viene restituito un errore se viene specificato lo spazio tabella e l’azione non è CREATE_ACTION. |
DBMS_REPAIR Eccezioni
| 942 | riparazione tabella non esiste |
| 1418 | indice specificato non esiste |
| 24120 | parametro non valido |
| 24121 | non è possibile specificare CASCADE_FLAG e un blocco di gamma |
| 24122 | blocco non valido gamma |
| 24124 | azione non valido parametro specificato |
| 24126 | CASCADE_FLAG specificato e oggetto non è una tabella |
| 24127 | tablespace specificato e l’azione non è CREATE_ACTION |
| 24128 | partizione specificata per non partizionato oggetto |
| 24129 | voci orfane chiave nome della tabella – deve avere ‘ORPHAN_’ prefisso |
| 24129 | specificata riparazione tabella non inizia con ‘REPAIR_’ prefisso |
| 24131 | riparazione tabella è errata colonne |
| 24132 | riparazione tabella di nome è troppo lungo |