Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In Common Log File System (CLFS), ogni record di log in un determinato flusso è identificato in modo univoco da un numero di sequenza di log (LSN). Quando si scrive un record in un flusso, viene restituito un LSN che identifica tale record per riferimento futuro.
I LSN creati per un determinato flusso formano una sequenza strettamente crescente. Ovvero, l'LSN assegnato a un record di log in un determinato flusso è sempre maggiore dei LSN assegnati ai record di log scritti in precedenza nello stesso flusso. Le funzioni seguenti sono disponibili per confrontare i nomi LSN dei record di log in un determinato flusso.
Le costanti CLFS_LSN_NULL e CLFS_LSN_INVALID sono i limiti inferiori e superiori per tutti i nomi LSN validi. Qualsiasi LSN valido è maggiore o uguale a CLFS_LSN_NULL. Inoltre, qualsiasi LSN valido è strettamente minore di CLFS_LSN_INVALID. CLFS_LSN_NULL è un LSN valido, mentre CLFS_LSN_INVALID non è un LSN valido. È anche possibile confrontare CLFS_LSN_INVALID con altri LSN usando le funzioni nell'elenco precedente.
Per ogni flusso, CLFS tiene traccia di due LSN speciali: l'LSN di base e l'ultimo LSN. Inoltre, ogni singolo record di log ha due LSN speciali (LSN precedente e LSN undo-next) che è possibile usare per creare catene di record di log correlati. Le sezioni seguenti descrivono in dettaglio questi LSN speciali.
Base LSN
Quando un client scrive il primo record in un flusso, CLFS imposta l'LSN di base al LSN di quel primo record. LSN di base rimane invariato fino a quando non viene modificato da un client. Quando i client del flusso non richiedono più i record prima di un determinato punto del flusso, possono aggiornare l'LSN di base chiamando ClfsAdvanceLogBase o ClfsWriteRestartArea. Ad esempio, se i client non necessitano più dei primi cinque record di log, possono impostare l'LSN di base sul numero LSN del sesto record.
Ultimo LSN
Quando i client scrivono record in un flusso, CLFS regola l'ultimo LSN in modo che sia sempre l'LSN dell'ultimo record scritto. Se i client non necessitano più dei record dopo un determinato punto del flusso, possono aggiornare l'ultimo LSN chiamando ClfsSetEndOfLog. Ad esempio, se i client non necessitano più di record scritti dopo il decimo record, è possibile troncare il flusso impostando l'ultimo LSN sull'LSN del decimo record.
Parte attiva di un flusso
La parte attiva di un flusso è la parte di un flusso che inizia con il record a cui punta l'LSN di base e termina con il record a cui punta l'ultimo LSN. Il diagramma seguente illustra come l'LSN di base e l'ultimo LSN delineano la parte attiva di un flusso.
Se un flusso ha una coda archivio, la parte attiva del flusso inizia al record a cui punta l'LSN di base o la coda archivio, a seconda di quale dei due è minore. Per altre informazioni sull'archiviazione, vedere Supporto CLFS per l'archiviazione.
LSN precedente
Si supponga che due transazioni di database attive (transazione A e transazione B) scrivano i record nello stesso flusso contemporaneamente. Ogni volta che la transazione A scrive un record, imposta l'LSN precedente del record sull'LSN del record di log precedente scritto dalla transazione A. Questo forma una catena di record di log, appartenenti alla transazione A, che può essere attraversata in ordine inverso. La catena termina con il primo record di log scritto dalla transazione A, con il relativo LSN precedente impostato su CLFS_LSN_INVALID. Analogamente, la transazione B crea la propria catena di record di log impostando l'LSN precedente di ogni record di log che scrive.
Le frecce nel diagramma seguente illustrano il modo in cui l'LSN precedente di un record di log punta al record precedente in una catena che appartiene a una determinata transazione.
Annulla LSN successivo
Si supponga che una transazione effettui cinque aggiornamenti a un oggetto dati in memoria volatile, esegue il rollback del quarto e del quinto aggiornamento e quindi esegue un sesto aggiornamento. Poiché la transazione esegue gli aggiornamenti, scrive i record di log 1, 2, 3, 4, 5, 5', 4', e 6. I record di log da 1 a 5 descrivono le modifiche apportate dagli aggiornamenti da 1 a 5. Il record 5' descrive le modifiche apportate durante il rollback dell'aggiornamento 5 e il record 4' descrive le modifiche apportate durante il rollback dell'aggiornamento 4. Infine, il record 6 descrive le modifiche apportate dall'aggiornamento 6. I numeri 1, 2, 3, 4, 5, 5', 4' e 6 non sono gli LSN dei record di log; sono solo numeri usati per denominare i record di log per questa discussione.
I record di log 5' e 4', che descrivono i rollback, sono denominati record di log di compensazione (CLR). La transazione imposta il prossimo LSN di annullamento di ogni CLR sul predecessore (tra i record scritti dalla transazione) del record di log il cui aggiornamento è stato annullato. In questo esempio, l'LSN di annullamento successivo del record 5' è l'LSN del record 4, e l'LSN di annullamento successivo del record 4' è l'LSN del record 3.
I record di log ordinari (che non sono CLRs) hanno i LSNs di annullamento successivo impostati sul record di log precedente scritto dalla stessa transazione. Vale a dire, per un record ordinario, l'LSN undo-next e l'LSN precedente sono gli stessi.
Si supponga ora che si verifichi un errore di sistema e, durante il ripristino di riavvio, è necessario eseguire il rollback dell'intera transazione. Il codice di ripristino legge il record di log 6. I dati nel record 6 indicano che il record 6 è un record ordinario (non CLR), quindi il codice di ripristino esegue il rollback dell'aggiornamento 6. Il codice di ripristino esamina quindi l'LSN di undo-next del record 6 e trova che punta al record 4'. I dati nel record 4' indicano che si tratta di un CLR, quindi il codice di ripristino non esegue il rollback dell'aggiornamento 4'. Controlla invece l'LSN successivo di record 4' e rileva che punta al record 3. Il record 3 non è un CLR, quindi il codice di ripristino esegue l'annullamento dell'aggiornamento 3. Gli aggiornamenti 5 e 4 non vengono ripristinati durante il recupero perché erano già stati ripristinati durante l'elaborazione ordinaria in avanti. Infine, il codice di ripristino esegue il rollback degli aggiornamenti 2 e 1.
Il diagramma seguente illustra in che modo l'UNDO-NEXT LSN fornisce un meccanismo che il codice di ripristino può utilizzare per saltare i record i cui aggiornamenti hanno già subito il rollback.
