sql-server-ce - solucion - error de crear para base de datos microsoft sqlserver smo
Resolver la corrupción en los archivos de base de datos de SQL Server Compact Edition (2)
Esto no es una consulta. Es un resumen de nuestra solución para solucionar el problema de la corrupción en los archivos de la Base de datos compacta de SQL con (casi) un éxito definitivo. SQLCE La corrupción es un problema muy común. Hemos recibido una gran ayuda de publicaciones anteriores en StackOverflow y, por lo tanto, de esta publicación.
Nuestro producto es una arquitectura de 3 niveles con el servidor ejecutándose como un servicio de Windows conectado a clientes ricos a través de .Net Remoting. Nuestro producto utiliza SQLCE desde 2006. Hemos pasado de v3.1 a v3.5 y ahora a v4.0. Tenemos una herramienta de OR-Mapping personalizada para algunos requisitos muy específicos. Hemos enfrentado problemas limitados con v3.1, hemos enfrentado más con v3.5 y v4.0.
Inicialmente con v3.5, implementamos SqlCeEngine.Repair . Pero solo elimina los datos dañados e intenta recrear una base de datos estable. Encontramos que las claves externas de las tablas afectadas desaparecieron. Tuvimos que acabar con esto inmediatamente. Comenzamos a notificar a los usuarios sobre la corrupción de la base de datos y restaurar la última copia de seguridad. Esto solo proporcionó un alivio temporal; El problema de las corrupciones seguía en pie.
Este año, adoptamos v4.0. Sin embargo, nuestra aplicación también introdujo varias características nuevas que aumentaron enormemente el número de llamadas a bases de datos. v4.0 comenzó bien, pero comenzó a dar problemas cuando aumentó el uso del software. Los daños ocurridos mientras la aplicación se estaba ejecutando no se debieron a fallas de Windows, apagados anormales o problemas con el disco. La base de datos acaba de corromperse.
La siguiente publicación cubre la solución que hemos ideado para este problema:
Si utiliza SQL Server CE 4.0, existe un problema conocido que puede evitar que los datos se vacíen en el disco (TODO). https://support.microsoft.com/en-us/kb/2979868 y la revisión https://support.microsoft.com/en-us/kb/2960153
En sus propias palabras:
Suponga que ha especificado el intervalo de descarga en el número máximo de segundos en la cadena de conexión antes de que las transacciones confirmadas se vacíen en el disco en Microsoft SQL Server Compact 4.0. En esta situación, las transacciones confirmadas pueden tardar mucho más tiempo que el intervalo de vaciado en vaciarse en el disco o incluso no se pueden vaciar en el disco. Además, la pérdida de datos ocurre si hay una terminación anormal del programa.
El hotfix que resuelve este problema se incluye en un paquete de actualización de hotfix a pedido para SQL Server Compact 4.0 Service Pack 1.
La solución proporcionada es utilizar transaction.Commit(CommitMode.Immediate) alrededor del bloque que desea asegurarse de que se vacíe
[Separando la consulta y la solución]
Aquí va cómo resolvimos el problema:
A) Objetos de conexión / comando / transacción de cierre / eliminación: Nos aseguramos de que no haya objetos de conexión, transacción u comando no utilizados y sin cerrar. Nuestra herramienta ORM se utilizó para crear nuevos objetos después de llamar a commit en la transacción, que en algunos casos quedaron inactivos. Esto redujo bastante el número de corrupciones en un 50%.
B) Desactivación de Auto-Shrink: el único procedimiento que se realizó en medio de una ejecución de la aplicación, sobre el cual no teníamos control, fue Auto-Shrink. Estábamos llamando a SqlCeEngine.Compact cuando se inicia la aplicación. Decidimos eliminar tanto la compactación como el encogimiento automático. Y para nuestra sorpresa, redujimos las corrupciones en otro 48%. Fue un disparo en la oscuridad, y no podíamos creer que el encogimiento automático podría haber causado tales problemas. Prácticamente resolvimos el problema con esa actualización.
C) Transacciones de base de datos sincronizadas: algunas corrupciones de base de datos siguen ocurriendo. ¡Sin que se detecten razones claras, decidimos sincronizar las transacciones de la base de datos! Sé que a muchas personas de bases de datos no les va a gustar esto. A mi tampoco me gusta. Introdujimos bloqueos en nuestro nivel intermedio para garantizar que solo una llamada modifique la base de datos a la vez. Nuestra mayor implementación es de 55 clientes que utilizan nuestro sistema simultáneamente. La sincronización de las llamadas a la base de datos apenas provocó un retraso de rendimiento visible. Más bien, la sincronización nos permitió implementar una llamada controlada por temporizador a SqlCeEngine.Compact a intervalos regulares. Sabíamos que Compact no era el culpable, y sentimos que Compaction es una llamada necesaria ya que reindexa la base de datos (nuestra solución hace muchas inserciones y elimina). Sin embargo, necesita funcionar exclusivamente; No hay llamadas de base de datos cuando se llama Compact. La sincronización nos permitió controlar eso durante la ejecución de una aplicación. Como lo hemos hecho, no hemos recibido un solo problema de corrupción de la base de datos. Ha pasado más de un mes. De casi 5 clientes en una semana, a cero en un mes.
El razonamiento básico que nos llevó a las ideas B y C es que SQLCE es una base de datos integrada. Las corrupciones son comunes a todas las soluciones de bases de datos integradas. Las soluciones de base de datos a gran escala funcionan de forma independiente y son compatibles con un servidor de base de datos 24x7 que administra las conexiones y otras tareas. Un sistema de base de datos incrustado no tiene tal sistema de soporte. La única etapa cuando está viva es cuando se abre una conexión.
Algunos punteros más: 1) Implementamos commit con CommitMode.Immediate, lo que hace que la propiedad Flush-Interval sea redundante. 2) AutoShrink está configurado en 100, lo que desactiva el procedimiento por completo 3) He aumentado el tiempo de espera de la conexión para permitir que las llamadas a la base de datos sincronizadas funcionen sin problemas. 4) Se llama compacta cuando se inicia la aplicación. En los casos en que los clientes no cierran su máquina, implementamos el temporizador para llamar a Compact cada 24 horas.
Espero que este post ayude a resolver problemas.