Condividi tramite


Gestione di database (SQL Server Compact)

Nel corso del tempo, la struttura interna di un database di Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) può diventare frammentata e determinare così uno spreco di spazio su disco. Se la frammentazione è eccessiva, si verifica un calo di prestazioni. Per evitare la frammentazione, utilizzare le funzionalità descritte di seguito per eseguire la manutenzione del database di SQL Server Compact 3.5.

Per ulteriori informazioni sull'utilizzo dei metodi e delle proprietà descritte in questo argomento, vedere System.Data.SqlServerCe.

Compact

È possibile utilizzare il metodo Compact (CompactDatabase nella programmazione nativa) per recuperare spazio nel file di database, nonché per modificare impostazioni del database quali la password e l'ID delle impostazioni locali (LCID).

I file di database di SQL Server Compact 3.5 sono divisi in unità logiche di 4 KB, denominate pagine. Con la continua modifica di un database, è possibile che alcune pagine contengano spazio inutilizzato e che altre risultino interamente inutilizzate. Le pagine inutilizzate verranno recuperate mediante il meccanismo AutoShrink. Per ulteriori informazioni, vedere la sezione "Autoshrink" più avanti in questo argomento.

Lo spazio vuoto nelle pagine può essere recuperato esclusivamente mediante il metodo Compact. Il metodo Compact legge le righe nel database di origine e scrive tali righe nel database di destinazione riducendo al minimo lo spreco di spazio.

Nota

Se per il database di destinazione non viene specificata la proprietà Data Source, il metodo Compact sovrascrive il database di origine con il nuovo database compattato, a cui viene assegnato lo stesso nome.

Quando un database viene compattato:

  • Viene ricreato un nuovo database e vengono creati nuovi indici.

  • Le pagine delle tabelle vengono riorganizzate in pagine di database adiacenti. Viene così migliorata l'allocazione dello spazio grazie alla riduzione della frammentazione delle tabelle nel database.

  • Lo spazio inutilizzato creato dalle eliminazioni di oggetti e record viene recuperato riscrivendo tutti i dati del database in nuove pagine di dati. Quando vengono eliminati oggetti o record dal database, lo spazio da essi occupato viene contrassegnato come disponibile per nuove aggiunte al database. A meno che non venga eliminata interamente, una pagina di dati resta in uno stato di riempimento parziale. Le dimensioni del database vengono ridotte soltanto in caso di eliminazione dei dati finali dalla pagina o di compattazione del database. Per i database con frequenti operazioni di aggiunta, eliminazione e aggiornamento di oggetti e record, è consigliabile eseguire spesso la compattazione.

  • Le colonne Identity in incremento vengono reimpostate affinché il successivo valore allocato sia superiore di un incremento rispetto al valore più elevato nei restanti record. Se ad esempio sono stati eliminati tutti i record del database, la compattazione del database determina l'impostazione del valore della colonna Identity del record successivo sul valore di inizializzazione. Se il restante valore Identity più elevato nel database è 50 e il valore di incremento è 5, la compattazione del database determina l'impostazione del valore del record successivo su 55. Ciò si verifica anche se in precedenza erano stati aggiunti record contenenti valori superiori a 50 che sono stati eliminati prima della compattazione. Il valore di incremento può anche essere negativo, ad esempio –5, e il valore minimo è 15. Con la compattazione del database, il valore del record successivo viene impostato su 10.

    Nota

    Questo comportamento si verifica se si utilizza la versione originale di Visual Studio 2008. La compattazione di un database non determina la modifica delle informazioni sulle identità in Visual Studio 2008 SP1.

  • Se nella stringa di connessione del database di destinazione vengono specificati valori per l'identificatore delle impostazioni locali o la password, questi valori verranno utilizzati al momento della creazione del database di destinazione.

Prima della compattazione di un database, assicurarsi che sussistano le condizioni seguenti:

  • Il database deve essere chiuso.
  • Il database di destinazione non deve esistere quando viene chiamato il metodo Compact. Se esiste già il database specificato in DestConnection o un altro file con lo stesso nome, si verifica un errore.
  • Deve essere disponibile spazio di archiviazione sufficiente per la versione originale e quella compattata del database, nonché per tutti i dati memorizzati nella cache e i dati archiviati nel database temporaneo.

Importante

Per utilizzare il metodo Compact, il dispositivo deve disporre di spazio libero almeno due volte superiore alla dimensione del database di origine.

Autoshrink

Per compattare un database, viene creato un nuovo database e quindi vengono copiati tutti gli oggetti dal database di origine al nuovo database. La compattazione in genere non viene avviata automaticamente. La regolazione automatica della dimensione di un file di database viene denominata AutoShrink. Poiché l'utilizzo di memoria e tempo di processore è ridotto al minimo, questa tecnica rappresenta la soluzione ideale soprattutto per i dispositivi palmari e i prodotti di database per dispositivi portatili. La tecnica Autoshrink determina lo spostamento delle pagine all'interno di un file in modo da disporre tutte le pagine vuote o non allocate alla fine del file. Le pagine vuote vengono quindi troncate e sono disponibili per l'utilizzo da parte del file system del database. La restituzione delle pagine troncate al file system del database incrementa lo spazio nel file system.

Per impostare Autoshrink, per il codice gestito utilizzare la proprietà della stringa di connessione AutoShrink Threshold. Per il codice nativo, utilizzare la proprietà DBPROP_SSCE_AUTO_SHRINK_THRESHOLD. che specifica la percentuale di spazio libero nel file prima dell'avvio di Autoshrink.

Nota

È inoltre possibile compattare un database chiamando il metodo Shrink. Per ulteriori informazioni, vedere System.Data.SqlServerCe.

Verify

I file di database di SQL Server Compact 3.5 sono divisi in unità logiche di 4 KB, denominate pagine. Al momento della scrittura di ogni pagina nel file di database, SQL Server Compact 3.5 calcola e salva un valore di checksum per la pagina. In caso di modifica o danneggiamento della pagina dopo la scrittura nel file, la pagina non corrisponderà più al valore di checksum previsto. Durante la lettura della pagina, SQL Server Compact 3.5 restituirà l'errore nativo SSCE_M_DATABASECORRUPTED (25017).

Chiamando il metodo Verify della classe SqlCeEngine, vengono ricalcolati i valori di checksum di ogni pagina del file di database e ne viene verificata la corrispondenza con i valori previsti. Se il metodo restituisce true, non si è verificato alcun danneggiamento del file di database. Se restituisce false, il file di database è stato danneggiato e l'applicazione deve chiamare il metodo Repair.

Repair

In caso di danneggiamento di un file di database, è possibile tentare di recuperare il file di database utilizzando il metodo Repair(System.String,System.Data.SqlServerCe.RepairOption) dell'oggetto SqlCeEngine oppure il metodo Repair dell'oggetto Programmazione dell'oggetto Engine (SQL Server Compact) nativo. Il metodo Repair esegue la scansione del database e calcola i valori di checksum delle pagine. Se un valore di checksum non corrisponde a quello calcolato in precedenza al momento della scrittura della pagina nel database, la pagina viene considerata danneggiata. Se il metodo Repair viene richiamato con il valore RepairOption.DeleteCorruptedRows, tutte le pagine danneggiate vengono eliminate. Se la pagina danneggiata contiene lo schema del database, ciò potrebbe causare la perdita di dati significativi. I dati recuperati mediante il metodo Repair, tuttavia, non dovrebbero essere in alcun modo danneggiati. Se il metodo Repair viene richiamato con il valore RepairOption.RecoverCorruptedRows, il database tenterà di leggere i dati delle pagine danneggiate. È così possibile recuperare una maggiore quantità di dati. L'utilizzo di questa opzione, tuttavia, non garantisce che i dati recuperati non siano danneggiati a livello logico.

Nota

Il metodo Repair si rivela utile soltanto se SQL Server Compact 3.5 restituisce l'errore nativo SSCE_M_DATABASECORRUPTED (25017) oppure se una chiamata al metodo Verify dell'oggetto SqlCeEngine restituisce false.

Autoflush

In caso di modifiche in un database causate da transazioni, le modifiche vengono mantenute nel pool di buffer fino al commit o all'interruzione della transazione. In caso di interruzione di una transazione, le modifiche vengono eliminate. In caso di commit della transazione, le modifiche diventano visibili per altri utenti e transazioni, ma è possibile che non vengano scritte immediatamente nel database. Se si verifica un arresto anomalo del programma che causa, ad esempio, il riavvio del dispositivo, le transazioni di cui è stato eseguito il commit ma le cui modifiche non sono state scritte nel database verranno eliminate.

Le transazioni vengono sempre scritte nel database nell'ordine in cui è stato eseguito il commit. In questo modo, il database è sempre coerente nonostante l'eventuale perdita di alcune transazioni. Si consideri ad esempio un'applicazione che esegue il commit della transazione A e quindi della transazione B. In caso di arresto anomalo dell'applicazione o di riavvio del dispositivo, il database si trova in uno degli stati seguenti:

  • Non modificato
  • Modificato dalla transazione A
  • Modificato da A e B

La scrittura delle transazioni nel database nell'ordine in cui viene eseguito il commit consente di migliorare le prestazioni riducendo il numero di operazioni di scrittura nel file di database. L'incremento delle prestazioni risulta significativo soprattutto in presenza di molte transazioni di piccole dimensioni di cui viene eseguito il commit in un breve intervallo di tempo. In questo caso, tutte le transazioni vengono scritte nel file di database contemporaneamente, anziché con una diversa operazione di scrittura nel database per ogni transazione.

Le modifiche in sospeso nel pool di buffer vengono scritte o scaricate nel database con l'intervallo di tempo specificato dalla proprietà della stringa di connessione Flush Interval di ADO .NET (DPROP_SSCE_FLUSH_INTERVAL in OLE DB). Con queste proprietà viene impostato il numero massimo di secondi prima che le transazioni di cui è stato eseguito il commit vengano scaricate su disco.

Nota

Per le transazioni che devono essere mantenute nel database quando ne viene eseguito il commit, l'applicazione può utilizzare l'enumerazione CommitMode o la proprietà DBPROP_SSCE_TRANSACTION_COMMIT_MODE di OLE DB per ignorare il funzionamento predefinito dello scaricamento in fase di commit. Grazie a queste proprietà, un'applicazione è in grado di garantire la persistenza di tutte le transazioni eseguite in un database.

Backup, ripristino e rimozione

Poiché SQL Server Compact 3.5 è un sistema di database basato su file, è possibile completare numerose attività di database comuni come il backup, il ripristino e l'eliminazione di un database mediante le API del file system.

  • Per eseguire il backup di un database, chiudere tutte le connessioni al database e quindi copiare il file con estensione sdf.
  • Per ripristinare un database, copiare nuovamente il file con estensione sdf nel normale percorso di lavoro. Queste operazioni possono essere eseguite anche se il database viene impostato per la replica.
  • Per rimuovere un database, eliminare il file di database con estensione sdf.

Vedere anche

Altre risorse

Metodo CompactDatabase (SQL Server Compact)
Metodo Repair (SQL Server Compact)

Guida e informazioni

Assistenza (SQL Server Compact 3.5 Service Pack 1)