Differenze tra le versioni di "Controllo di integrità file del Repository Documentale"
imported>Root |
imported>Root |
||
(7 versioni intermedie di uno stesso utente non sono mostrate) | |||
Riga 2: | Riga 2: | ||
==Come e' strutturata una libreria di repository== | ==Come e' strutturata una libreria di repository== | ||
Ogni libreria di repository è composta da due elementi principali: la tabella di definizione dei documenti, presente nel database e la cartella dei file fisici dei documenti presente nel file system. Si noti che la | Ogni libreria di repository è composta da due elementi principali: la tabella di definizione dei documenti, presente nel database e la cartella dei file fisici dei documenti presente nel file system. Si noti che la cartella dei file fisici è una cartella con un percorso relativo al server applicativo e non al client che si sta utilizzando. Infatti l'accesso ai file fisici viene sempre mediato dal server applicativo, che preleva i file per inviarli al client oppure riceve i nuovi file dal client e li scrive nel file system. Il client non ha '''mai''' accesso diretto al file fisico. | ||
La definizione dei documenti, presente nel database, contiene informazioni sul nome e la descrizione del documento, sugli attributi di creazione, sui metadati associati, sui documenti correlati, sui diritti di accesso e via dicendo. In sostanza tutte le informazioni "satellite" associate al documento sono presenti nel database. Il file vero e proprio del documento invece è memorizzato fuori dal database, per questioni di performance legate all'archivio. | La definizione dei documenti, presente nel database, contiene informazioni sul nome e la descrizione del documento, sugli attributi di creazione, sui metadati associati, sui documenti correlati, sui diritti di accesso e via dicendo. In sostanza tutte le informazioni "satellite" associate al documento sono presenti nel database. Il file vero e proprio del documento invece è memorizzato fuori dal database, per questioni di performance legate all'archivio. | ||
Riga 11: | Riga 11: | ||
==Tipi di analisi== | ==Tipi di analisi== | ||
Sono presenti | Sono presenti varie modalità di analisi dei problemi, e rappresentano diversi bilanciamenti tra prestazioni e risultati. | ||
Quando si avvia una nuova analisi si presenta una interfaccia che permette all'utente di specificare tramite spunte quali sono gli aspetti dell'analisi che gli interessano. Sulla base delle varie combinazioni di spunte attivate, la frame deduce la modalità operativa da avviare (compare il codice nella barra di stato). | |||
=== | ===ANALYZE_UNCOMMITTED_DELS=== | ||
Ricerca veloce dei file di cancellazione non committati. Tali file restano come refuso di una transazione mal committata, sostanzialmente a causa di (vecchi) bug del transaction manager del vanilla driver (ora corretti). E' possibile, anche se improbabile, che questi file rimangano nel file system anche a fronte di un crash dell'application server. | |||
=== | === ANALYZE_FILE_ORPHANS === | ||
Ricerca dei file che non hanno corrispondenza nel database. Il punto di partenza e' il file system, e per ogni file viene controllato se esiste il record nel database. Questa modalità sottintende anche '''ANALYZE_UNCOMMITTED_DELS'''. | |||
'''''Nota:''' Questa modalità non trova necessariamente tutti i '''record '''senza file.'' | |||
=== ANALYZE_DB_ORPHANS === | |||
Ricerca dei record che non hanno corrispondenze nel file system. Il punto di partenza è il database, e per ogni record viene controllato se esiste il file corrispondente. | |||
'''''Nota:''' Questa modalità non trova necessariamente tutti i '''file '''orfani.'' | |||
=== ANALYZE_SIMPLE === | |||
L'analisi semplificata effettua un controllo incrociato tra database e file system (è la somma di '''ANALYZE_FILE_ORPHANS''' e '''ANALYZE_DB_ORPHANS''') eseguendo prima la scansione dei file e poi la scansione del database. Trova tutte le incongruenze (record senza file e file orfani) ma in caso di problemi non è in grado di suggerire correzioni. Per cui risulta un sistema bilanciato solo per accertarsi che non vi siano orfani nel sistema. | |||
''' | === ANALYZE_ORPHANS_RELINK === | ||
Questa analisi è una estensione di '''ANALYZE_SIMPLE'''. Per ogni anomalia trovata viene cercata la soluzione tramite il calcolo delle firme dei file. Il calcolo delle firme è limitato ai casi di anomalia per cui questa modalità è più veloce di '''ANALYZE_FULL '''in caso di librerie per la maggior parte corrette. | |||
===ANALYZE_FULL=== | |||
Questa analisi è una estensione di '''ANALYZE_ORPHANS_RELINK''', ed aggiunge il controllo delle firme anche per i file che già combaciano correttamente (per nome) con il database. Questa modalità è la più pesante ma garantisce il controllo più preciso dato che è in grado di rilevare anche record che puntano a file esistenti ma con la firma sbagliata. | |||
===Quale tipo di analisi utilizzare?=== | |||
Sostanzialmente è una questione di tempistiche. Più l'analisi è approfondita, più tempo impiega. E' possibile mitigare i tempi di esecuzione delle analisi più pesanti specificando intervalli di date per limitare le ricerche sul database e nel file system, anche se <u>è importante sottolineare</u> che intervalli mal impostati faranno fallire il calcolo delle soluzioni, per cui è obbligatorio avere le idee ben chiare prima di limitare per data le ricerche. | |||
==Possibili problemi== | ==Possibili problemi== | ||
Riga 32: | Riga 44: | ||
===Il file non e' presente nel database e non e' recuperabile=== | ===Il file non e' presente nel database e non e' recuperabile=== | ||
E' stato trovato un file che non ha corrispondenza nel database. | E' stato trovato un file che non ha corrispondenza nel database. Quando questo accade, il sistema cerca informazioni di recupero in un file satellite che normalmente è presente nella stessa cartella del file principale. Questo file satellite contiene un insieme di informazioni di base che permettono di reinserire alcune informazioni (non tutte) nel database e quindi di ricollegare il file al sistema. Vengono recuperate informazioni quali nome del file e descrizione, ma non vengono recuperate informazioni relative ai metadati oppure ai permessi di accesso. Se il file di recupero non viene trovato, si verifica questo problema. Il problema non ha soluzione automatica. | ||
===Il file non e' presente nel database ma e' recuperabile parzialmente=== | ===Il file non e' presente nel database ma e' recuperabile parzialmente=== | ||
Riga 38: | Riga 50: | ||
===Non e' stato possibile recuperare il file a causa di problemi nel file di recupero=== | ===Non e' stato possibile recuperare il file a causa di problemi nel file di recupero=== | ||
Si e' verificata la situazione del caso precedente ed e' stato tentato il recupero del file, ma i dati di | Si e' verificata la situazione del caso precedente ed e' stato tentato il recupero del file, ma i dati di recupero non sono stati letti correttamente. Questo problema potrebbe essere causato dal fatto che il file di recupero è stato alterato manualmente con un editor non adatto. Il problema non ha soluzione automatica, è un caso che dev'essere valutato singolarmente. | ||
===Il documento non punta ad alcun file=== | ===Il documento non punta ad alcun file=== | ||
Riga 50: | Riga 62: | ||
===Il documento punta ad un file con firma non coincidente=== | ===Il documento punta ad un file con firma non coincidente=== | ||
Questo tipo di problema è l'unico che non viene rilevato dall'analisi semplificata. E' altresì vero che una situazione del genere ha una bassissima probabilità di verificarsi, ed è stata contemplata solo per completezza. | Questo tipo di problema è l'unico che non viene rilevato dall'analisi semplificata. E' altresì vero che una situazione del genere ha una bassissima probabilità di verificarsi, ed è stata contemplata solo per completezza. Ad ogni modo se esiste un file con la firma corretta, una analisi completa risolve il problema. | ||
===Un documento condivide il file con altri documenti=== | ===Un documento condivide il file con altri documenti=== | ||
Riga 57: | Riga 69: | ||
===Il file viene utilizzato da un'altra libreria=== | ===Il file viene utilizzato da un'altra libreria=== | ||
Questa situazione si verifica quando sono stati commessi degli errori nella gestione dei percorsi cartella di differenti librerie. Ad esempio, è stata fatta puntare una libreria ad una cartella contenuta o che contiene la cartella di una differente libreria. La situazione normale richiede che le cartelle siano distinte e non che sia includano a vicenda. Il problema non ha soluzione automatica. | Questa situazione si verifica quando sono stati commessi degli errori nella gestione dei percorsi cartella di differenti librerie. Ad esempio, è stata fatta puntare una libreria ad una cartella contenuta o che contiene la cartella di una differente libreria. La situazione normale richiede che le cartelle siano distinte e non che sia includano a vicenda. Il problema non ha soluzione automatica. | ||
=== Il file è il refuso di una cancellazione === | |||
Si veda la spiegazione di '''ANALYZE_UNCOMMITTED_DELS'''. | |||
Esiste la possibilità che questi file, pur segnalati come correggibili dall'algoritmo, in fase di correzione non lo siano. Questo perché il sistema quando tenta di correggere il file (sostanzialmente, rinominandolo) trova già il file corretto al suo posto. In tal caso piuttosto che rimuovere file creando potenziali perdite di informazione, il sistema si limita a stampare dei warning nel log del server. | |||
==Perchè si verificano questi problemi?== | |||
Il motore di Repository Documentale interno dell'applicativo è in grado di gestire tutte le situazioni in modo robusto ed affidabile. Perchè allora si verificano questi problemi? | |||
Da molti casi sottoposti ad assistenza è emerso che la quasi totalità dei problemi è stata causata da una amministrazione poco oculata delle informazioni. Situazioni quali: spostamento manuale delle cartelle nel file system, restore di backup vecchi, utilizzo di database generati da altri server applicativi e molte altre varianti di queste situazioni sono solitamente causa di problemi con il repository documentale. | |||
E' importante tenere a mente che il repository documentale si basa simultaneamente su database e file system, pertanto quando si operano operazioni di manutenzione è necessario considerare entrambi gli aspetti. |
Versione attuale delle 18:10, 3 nov 2017
La maschera di controllo integrità permette di effettuare una verifica di consistenza tra i dati presenti nel database e i file presenti nel file system.
Come e' strutturata una libreria di repository
Ogni libreria di repository è composta da due elementi principali: la tabella di definizione dei documenti, presente nel database e la cartella dei file fisici dei documenti presente nel file system. Si noti che la cartella dei file fisici è una cartella con un percorso relativo al server applicativo e non al client che si sta utilizzando. Infatti l'accesso ai file fisici viene sempre mediato dal server applicativo, che preleva i file per inviarli al client oppure riceve i nuovi file dal client e li scrive nel file system. Il client non ha mai accesso diretto al file fisico.
La definizione dei documenti, presente nel database, contiene informazioni sul nome e la descrizione del documento, sugli attributi di creazione, sui metadati associati, sui documenti correlati, sui diritti di accesso e via dicendo. In sostanza tutte le informazioni "satellite" associate al documento sono presenti nel database. Il file vero e proprio del documento invece è memorizzato fuori dal database, per questioni di performance legate all'archivio.
Il driver di repository si prende carico di mantenere allineate le informazioni presenti nel database e i file presenti nel file system. E' tuttavia possibile, a causa di molteplici motivi (principalmente legati a problemi di amministrazione) che le informazioni presenti nel database e i file presenti nel file system vengano disallineati.
Questa funzione ha lo scopo di controllare la consistenza delle informazioni e, se possibile, di effettuare delle operazioni per riportare le informazioni ad uno stato consistente.
Tipi di analisi
Sono presenti varie modalità di analisi dei problemi, e rappresentano diversi bilanciamenti tra prestazioni e risultati.
Quando si avvia una nuova analisi si presenta una interfaccia che permette all'utente di specificare tramite spunte quali sono gli aspetti dell'analisi che gli interessano. Sulla base delle varie combinazioni di spunte attivate, la frame deduce la modalità operativa da avviare (compare il codice nella barra di stato).
ANALYZE_UNCOMMITTED_DELS
Ricerca veloce dei file di cancellazione non committati. Tali file restano come refuso di una transazione mal committata, sostanzialmente a causa di (vecchi) bug del transaction manager del vanilla driver (ora corretti). E' possibile, anche se improbabile, che questi file rimangano nel file system anche a fronte di un crash dell'application server.
ANALYZE_FILE_ORPHANS
Ricerca dei file che non hanno corrispondenza nel database. Il punto di partenza e' il file system, e per ogni file viene controllato se esiste il record nel database. Questa modalità sottintende anche ANALYZE_UNCOMMITTED_DELS.
Nota: Questa modalità non trova necessariamente tutti i record senza file.
ANALYZE_DB_ORPHANS
Ricerca dei record che non hanno corrispondenze nel file system. Il punto di partenza è il database, e per ogni record viene controllato se esiste il file corrispondente.
Nota: Questa modalità non trova necessariamente tutti i file orfani.
ANALYZE_SIMPLE
L'analisi semplificata effettua un controllo incrociato tra database e file system (è la somma di ANALYZE_FILE_ORPHANS e ANALYZE_DB_ORPHANS) eseguendo prima la scansione dei file e poi la scansione del database. Trova tutte le incongruenze (record senza file e file orfani) ma in caso di problemi non è in grado di suggerire correzioni. Per cui risulta un sistema bilanciato solo per accertarsi che non vi siano orfani nel sistema.
ANALYZE_ORPHANS_RELINK
Questa analisi è una estensione di ANALYZE_SIMPLE. Per ogni anomalia trovata viene cercata la soluzione tramite il calcolo delle firme dei file. Il calcolo delle firme è limitato ai casi di anomalia per cui questa modalità è più veloce di ANALYZE_FULL in caso di librerie per la maggior parte corrette.
ANALYZE_FULL
Questa analisi è una estensione di ANALYZE_ORPHANS_RELINK, ed aggiunge il controllo delle firme anche per i file che già combaciano correttamente (per nome) con il database. Questa modalità è la più pesante ma garantisce il controllo più preciso dato che è in grado di rilevare anche record che puntano a file esistenti ma con la firma sbagliata.
Quale tipo di analisi utilizzare?
Sostanzialmente è una questione di tempistiche. Più l'analisi è approfondita, più tempo impiega. E' possibile mitigare i tempi di esecuzione delle analisi più pesanti specificando intervalli di date per limitare le ricerche sul database e nel file system, anche se è importante sottolineare che intervalli mal impostati faranno fallire il calcolo delle soluzioni, per cui è obbligatorio avere le idee ben chiare prima di limitare per data le ricerche.
Possibili problemi
Per semplicità espositiva chiameremo documento l'informazione presente nel database e file l'informazione presente nel file system. Quindi ad ogni documento corrisponde un file. Quando un documento è stato memorizzato tenendo traccia delle versioni, è possibile che ad ogni documento corrispondano uno o più file (il file corrente e le vecchie versioni).
Il file non e' presente nel database e non e' recuperabile
E' stato trovato un file che non ha corrispondenza nel database. Quando questo accade, il sistema cerca informazioni di recupero in un file satellite che normalmente è presente nella stessa cartella del file principale. Questo file satellite contiene un insieme di informazioni di base che permettono di reinserire alcune informazioni (non tutte) nel database e quindi di ricollegare il file al sistema. Vengono recuperate informazioni quali nome del file e descrizione, ma non vengono recuperate informazioni relative ai metadati oppure ai permessi di accesso. Se il file di recupero non viene trovato, si verifica questo problema. Il problema non ha soluzione automatica.
Il file non e' presente nel database ma e' recuperabile parzialmente
Si è verificata una situazione simile alla precedente, solo che in questo caso il file di recupero è stato trovato e quindi si può procedere alla ricostruzione delle informazioni sul database.
Non e' stato possibile recuperare il file a causa di problemi nel file di recupero
Si e' verificata la situazione del caso precedente ed e' stato tentato il recupero del file, ma i dati di recupero non sono stati letti correttamente. Questo problema potrebbe essere causato dal fatto che il file di recupero è stato alterato manualmente con un editor non adatto. Il problema non ha soluzione automatica, è un caso che dev'essere valutato singolarmente.
Il documento non punta ad alcun file
E' un caso improbabile ma è stato incluso per completezza. In questo caso il documento nel database non contiene alcuna informazione che permette di risalire al file relativo. Se inoltre mancano anche informazioni sulla firma del documento, il problema non è risolvibile.
Il documento punta ad un file inesistente e non esistono altri file compatibili
Non è stato trovato il file puntato dal documento. Non sono stati trovati altri file che potrebbero rimpiazzarlo. Potrebbe darsi che esistano file di rimpiazzo con la stessa firma ma nome diverso, solo che è stata eseguita l'analisi semplificata che non è in grado di fornire queste soluzioni. In tal caso una esecuzione dell'analisi completa potrebbe risolvere il problema.
Il documento punta ad un file inesistente, ma un altro file ha la stessa firma
Si è verificata una situazione simile alla precedente, solo che è stata eseguita l'analisi completa e questa ha trovato un file con la stessa firma anche se con nome differente. In questo caso il problema viene risolto facendo puntare il documento al nuovo file trovato.
Il documento punta ad un file con firma non coincidente
Questo tipo di problema è l'unico che non viene rilevato dall'analisi semplificata. E' altresì vero che una situazione del genere ha una bassissima probabilità di verificarsi, ed è stata contemplata solo per completezza. Ad ogni modo se esiste un file con la firma corretta, una analisi completa risolve il problema.
Un documento condivide il file con altri documenti
Potrebbe accadere che più documenti puntino allo stesso file. In questo caso il tutto funziona correttamente ma questa situazione è comunque una anomalia che viene segnalata. Il problema non ha soluzione automatica.
Il file viene utilizzato da un'altra libreria
Questa situazione si verifica quando sono stati commessi degli errori nella gestione dei percorsi cartella di differenti librerie. Ad esempio, è stata fatta puntare una libreria ad una cartella contenuta o che contiene la cartella di una differente libreria. La situazione normale richiede che le cartelle siano distinte e non che sia includano a vicenda. Il problema non ha soluzione automatica.
Il file è il refuso di una cancellazione
Si veda la spiegazione di ANALYZE_UNCOMMITTED_DELS.
Esiste la possibilità che questi file, pur segnalati come correggibili dall'algoritmo, in fase di correzione non lo siano. Questo perché il sistema quando tenta di correggere il file (sostanzialmente, rinominandolo) trova già il file corretto al suo posto. In tal caso piuttosto che rimuovere file creando potenziali perdite di informazione, il sistema si limita a stampare dei warning nel log del server.
Perchè si verificano questi problemi?
Il motore di Repository Documentale interno dell'applicativo è in grado di gestire tutte le situazioni in modo robusto ed affidabile. Perchè allora si verificano questi problemi?
Da molti casi sottoposti ad assistenza è emerso che la quasi totalità dei problemi è stata causata da una amministrazione poco oculata delle informazioni. Situazioni quali: spostamento manuale delle cartelle nel file system, restore di backup vecchi, utilizzo di database generati da altri server applicativi e molte altre varianti di queste situazioni sono solitamente causa di problemi con il repository documentale.
E' importante tenere a mente che il repository documentale si basa simultaneamente su database e file system, pertanto quando si operano operazioni di manutenzione è necessario considerare entrambi gli aspetti.