Mantendo bancos de dados (SQL Server Compact)
A estrutura interna de um banco de dados Microsoft SQL Server Compact 3.5 pode ser fragmentada com o tempo, resultando na perda de espaço em disco. Se for a fragmentação for excessiva, o desempenho pode diminuir. Para evitar fragmentação, use os seguintes recursos para manter o banco de dados SQL Server Compact 3.5.
Para obter mais informações sobre como usar as propriedades e os métodos descritos neste tópico, consulte System.Data.SqlServerCe.
Compactar
Você usa o método Compact (o método CompactDatabase na programação nativa) para recuperar espaço no arquivo de banco de dados. Você também pode usá-lo para alterar configurações do banco de dados como a senha e o LCID (identificação de local).
Os arquivos do banco de dados SQL Server Compact 3.5 são divididos em unidades lógicas de 4 KB conhecidas como páginas. Como um banco de dados continua a ser modificado, algumas páginas podem conter espaços não utilizados e outras não são usadas. As páginas não utilizadas são eventualmente recuperadas pelo mecanismo AutoShrink. Para obter mais informações, consulte a seção "Redução automática" mais adiante neste tópico.
O espaço vazio nas páginas pode ser recuperado apenas usando o método Compact. O método Compact lê as linhas do banco de dados de origem e as grava no banco de dados de destino, desperdiçando uma quantidade mínima de espaço no banco de dados de destino.
Observação
Se a propriedade Data Source não for especificada para o banco de dados de destino, o método Compact substituirá o banco de dados de origem pelo novo banco de dados compactado e terá o mesmo nome.
Quando você compacta um banco de dados:
Um novo banco de dados é recriado e novos índices são criados.
As páginas da tabela são reorganizadas para que residam em páginas adjacentes do banco de dados. Isso melhora a alocação de espaço reduzindo a fragmentação da tabela no banco de dados.
O espaço não utilizado criado pelas exclusões de objetos e registros é recuperado ao gravar novamente todos os dados do banco de dados em novas páginas de dados. Quando objetos ou registros são excluídos do banco de dados, o espaço que eles ocupavam é marcado como disponível para novas adições no banco de dados. A menos que uma página inteira de dados seja excluída, ela permanece em um estado parcialmente preenchido. O banco de dados não é reduzido até que os dados finais sejam excluídos da página ou ele seja compactado. Para bancos de dados nos quais objetos e registros são adicionados, excluídos e atualizados com freqüência, recomendamos que a compactação seja feita sempre.
As colunas de identidade incremental são redefinidas para que o próximo valor alocado seja um valor de etapa maior que o valor mais alto nos registros restantes. Por exemplo, se todos os registros no banco de dados tiverem sido excluídos, a compactação do banco de dados definirá o valor da coluna de identidade do próximo registro para o valor de partida. Se o maior valor de identidade restante no banco de dados for 50 e o valor de etapa for 5, a compactação do banco de dados definirá o valor do próximo registro como 55. Isso ocorrerá até mesmo se os registros que contêm valores maiores que 50 forem adicionados anteriormente, mas forem excluídos antes da compactação. O valor de etapa também pode ser negativo, por exemplo -5, e o valor mínimo é 15. A compactação do banco de dados define o valor do próximo registro como 10.
Observação
Esse comportamento ocorre se você estiver usando a versão de lançamento original do Visual Studio 2008. A compactação do banco de dados não altera as informações de identidade no Visual Studio 2008 SP1.
Se os valores forem especificados para o identificador de local ou senha na seqüência de conexão do banco de dados de destino, eles serão usados ao criar o banco de dados de destino.
Antes de compactar um banco de dados, verifique se seguintes condições são verdadeiras:
O banco de dados deve estar fechado.
O banco de dados de destino não deve existir quando o método Compact for chamado. Ocorrerá um erro se o banco de dados especificado por DestConnection ou outro arquivo com o esse nome já existir.
Deve haver espaço de armazenamento suficiente para as versões originais e compactadas do banco de dados, além de todos os dados armazenados em cache e no banco de dados temporário.
Importante
Para usar o método Compact, seu dispositivo deve ter, no mínimo, espaço livre equivalente ao dobro do tamanho do banco de dados de origem.
Redução automática
Para compactar um banco de dados, crie um novo banco de dados e depois copie todos os objetos do banco de dados de origem para o novo banco de dados. Normalmente, a compactação não é iniciada automaticamente. O ajuste automático do tamanho de um arquivo do banco de dados é chamado de AutoShrink. Essa técnica não usa quase nenhuma memória e tempo do processador, o que a torna especialmente adequada a dispositivos de mão e produtos de bancos de dados móveis. A técnica Autoshrink move as páginas de um arquivo para que todas as páginas vazias ou que não foram alocadas sejam posicionadas de forma contígua no final do arquivo. As páginas vazias são então truncadas. Depois, as páginas truncadas são disponibilizadas para uso do sistema de arquivos do banco de dados. Retornar as páginas truncadas para o sistema de arquivos do banco de dados aumenta o espaço do sistema de arquivos.
Para definir Autoshrink, para o código gerenciado, use a propriedade da seqüência de conexão AutoShrink Threshold. Para código nativo, use a propriedade DBPROP_SSCE_AUTO_SHRINK_THRESHOLD. A propriedade especifica a porcentagem de espaço livre no arquivo antes que Autoshrink se inicie.
Observação
Você também pode reduzir um banco de dados chamando o método Shrink. Para obter mais informações, consulte System.Data.SqlServerCe.
Verificar
Os arquivos do banco de dados SQL Server Compact 3.5 são divididos em unidades lógicas de 4 KB chamadas páginas. Conforme cada página é gravada no arquivo do banco de dados, o SQL Server Compact 3.5 calcula e salva uma soma de verificação para essa página. Se a página for modificada ou corrompida depois de ser gravada no arquivo, ela não corresponderá mais à sua soma de verificação esperada. Quando o SQL Server Compact 3.5 lê esta página, ela retorna o erro nativo SSCE_M_DATABASECORRUPTED (25017).
Chamar o método Verify da classe SqlCeEngine recalculará as somas de verificação de todas as páginas no arquivo de banco de dados e verificará se tais somas correspondem aos seus valores esperados. Se esse método retornar true, o arquivo de banco de dados não foi corrompido. Se esse método retornar false, o arquivo de banco de dados foi corrompido e o aplicativo deverá chamar o método Repair.
Reparar
Se o arquivo de banco de dados for corrompido, você poderá tentar recuperá-lo usando o método Repair(System.String,System.Data.SqlServerCe.RepairOption) do objeto SqlCeEngine ou o método Repair do Programando o objeto Engine (SQL Server Compact) nativo. O método Repair examina o banco de dados e calcula as somas de verificação da página. Se uma soma de verificação não corresponder à soma de verificação calculada anteriormente quando aquela página foi gravada no banco de dados, essa página será considerada corrompida. Se o método Repair for chamado com o valor RepairOption.DeleteCorruptedRows, todas as páginas corrompidas serão descartadas. Isso poderá causar uma perda de dados significativa se a página corrompida contiver um esquema de banco de dados. No entanto, os dados recuperados usando o método Repair devem estar livres de corrupção. Se o método Repair for chamado com o valor RepairOption.RecoverCorruptedRows, o banco de dados tentará ler os dados das páginas corrompidas. Isso pode fazer com que mais dados sejam recuperados. No entanto, o uso dessa opção não garante que os dados recuperados fiquem livres da corrupção lógica.
Observação
O método Repair só será útil se o SQL Server Compact 3.5 retornar o erro nativo SSCE_M_DATABASECORRUPTED (25017), ou se uma chamada para o método Verify do objeto SqlCeEngine retornar false.
Liberação automática
Quando ocorrem alterações em um banco de dados devido às transações, essas alterações são mantidas no pool de buffers até que a transação seja confirmada ou anulada. Se uma transação for anulada, suas alterações serão descartadas. Se uma transação for confirmada, suas alterações ficarão visíveis para outros usuários e transações, mas elas poderão não ser imediatamente gravadas no banco de dados. Se houver um término anormal do programa, como uma redefinição de dispositivo, as transações que foram confirmadas, mas cujas alterações não foram gravadas no banco de dados, serão descartadas.
Observe que as transações são sempre gravadas no banco de dados na ordem na qual são confirmadas. Isso significa que embora algumas transações possam ser perdidas, o banco de dados é sempre consistente. Por exemplo, considere o caso no qual um aplicativo tem a transação A confirmada e, em seguida, a transação B. Se o aplicativo travar ou o dispositivo for redefinido, o banco de dados estará em um dos três estados:
Inalterado
Alterado pela transação A
Alterado pelas transações A e B
Gravar as transações no banco de dados na ordem na qual elas são confirmadas melhora o desempenho, reduzindo o número de vezes que o arquivo de banco de dados deve ser gravado. O desempenho aperfeiçoado é particularmente notável quando há muitas transações pequenas confirmadas em um breve período de tempo. Nesse caso, todas as transações são gravadas no arquivo de banco de dados ao mesmo tempo, e não individualmente, causando uma operação de gravação de banco de dados separada.
As alterações pendentes no pool de buffers são gravadas ou liberadas para o banco de dados no mesmo momento dos intervalos especificados pela propriedade da seqüência de conexão Flush Interval no ADO .NET (propriedade DPROP_SSCE_FLUSH_INTERVAL no OLE DB). Essas propriedades definem o número máximo de segundos antes da liberação das transações confirmadas para o disco.
Observação
Para transações que devem ser persistentes para o banco de dados quando são confirmadas, o aplicativo pode usar a enumeração CommitMode (ou a propriedade DBPROP_SSCE_TRANSACTION_COMMIT_MODE no OLE DB) para substituir o comportamento de liberação padrão no momento da confirmação. Usando essas propriedades, um aplicativo pode garantir que todas as transações ocorridas em um banco de dados tenham êxito na persistência.
Fazer backup/restaurar/descartar
Como o SQL Server Compact 3.5 é um sistema de banco de dados baseado em arquivo, você pode realizar várias tarefas comuns de banco de dados, como fazer backup, restaurar e excluir um banco de dados usando as APIs do sistema de arquivos.
Para fazer backup de um banco de dados, feche todas as conexões com o banco de dados e copie o arquivo .sdf.
Para restaurar um banco de dados, copie o arquivo .sdf novamente para seu local de trabalho regular. Essas operações funcionam mesmo se o banco de dados estiver configurado para replicação.
Para descartar um banco de dados, exclua o arquivo de banco de dados .sdf.