La résilience aux plantages de SQL Server peut-elle être améliorée?

Nous avons des PC exécutant SQL Server (2008 SP4 et 2016 SP1) qui perdent régulièrement de la puissance. Évidemment, cela conduit parfois à une corruption (index) de la base de données SQL Server, que nous devons restaurer par la suite.

Je suis conscient que SQL Server n'est pas conçu pour de tels scénarios et la bonne solution consiste à corriger la cause de la coupure de courant (plus d'informations ci-dessous, si vous êtes curieux). Néanmoins, existe-t-il des options de réglage dans SQL Server que je peux définir pour réduire le risque de corruption de la base de données en cas de coupure de courant ?

Contexte: Le "PC" est une tablette Windows montée sur un chariot élévateur. Lorsque l'utilisateur éteint le chariot élévateur, la tablette perd de la puissance. Nous avons essayé d'apprendre aux utilisateurs à fermer correctement Windows avant d'éteindre le chariot élévateur, mais nous avons échoué (probablement parce que le désactiver "fonctionne" la plupart du temps). Nous étudions également actuellement d'autres options, telles que l'ajout d'un onduleur qui signale à la tablette de s'arrêter en cas de coupure de courant.

Je suis conscient que SQL Server n'est pas conçu pour de tels scénarios et la bonne solution est de corriger la cause de la panne de courant […]

En fait, il est conçu pour faire face à la perte de puissance, c'est pourquoi il y a des choses comme l'écriture à l'avance (WAL) et la récupération après incident au démarrage (ou comme vous voulez l'appeler). L'une des façons de le faire est de choisir de ne pas mettre en cache les écritures qui semblent être ce que fait la tablette, d'où la corruption.

Néanmoins, existe-t-il des options de réglage dans SQL Server que je peux définir pour réduire le risque de corruption de la base de données en cas de coupure de courant?

Non, SQL Server fait ce qu'il devrait. Vous devez regarder soit en dehors de SQL Server (paramètres Windows pour la mise en cache des lecteurs [que SQL veut désactiver mais nous ne pouvons pas vous forcer], les mises à jour matérielles / firmware, etc.) ou, comme Eric l'a dit, acheter une alimentation externe pour relativement bon marché, ce qui pourrait résoudre les symptômes (le problème réel est probablement un type de mise en cache ou d'écriture sur batterie qui n'est pas réellement soutenu).

Si la tablette dispose d'une batterie qui fonctionne , vous pouvez configurer Windows pour qu'il s'éteigne lorsque la batterie est faible .

Si la tablette a une batterie qui ne fonctionne pas , pensez à remplacer la batterie. (J'ai eu des ordinateurs portables comme ça - vous seriez surpris de voir à quel point les batteries de remplacement peu coûteuses peuvent être sur eBay. Elles ne fonctionnent pas aussi bien que les OEM, mais bon, rien de mieux que rien dans cette situation.)

Si la tablette n'a pas du tout de capacité de batterie , envisagez d'ajouter une petite alimentation sans coupure (UPS) avec des sorties USB qui peut communiquer avec Windows pour lui dire quand elle fonctionne sur batterie. (Par exemple, j'ai mon propre bureau configuré pour s'éteindre lorsque l'onduleur est faible sur batterie - de cette façon, il s'éteindra en cas de panne de courant même si je ne suis pas à la maison.)

Si aucune de ces options n'est possible, vous n'avez pas de chance. Il s'agit d'un vieux livre blanc, mais les principes de base des E / S SQL Server 2000 de Microsoft expliquent essentiellement que vous avez besoin d'un sous-système d'E / S capable de gérer les pannes de courant avec élégance.

Il existe des options que vous pouvez utiliser pour augmenter le risque - comme la durabilité différée ou les tables en mémoire seule (non durables) - mais par défaut, SQL Server fait déjà de son mieux pour maximiser la fiabilité à chaque écriture dans le journal des transactions. Si même l'écriture du journal des transactions ne peut pas être garantie en raison de coupures de courant aléatoires, dépensez 100 $ sur une batterie UPS.

En supposant que vous ayez une base de données locale sur le chariot élévateur plutôt qu'un serveur en raison de connexions sans fil irrégulières? Évidemment, retirer SQL du chariot élévateur serait la solution préférable.

Quoi qu'il en soit, comme l'a suggéré Brent, réglez la tablette pour qu'elle s'éteigne d'elle-même après x minutes d'utilisation de la batterie ou certains critères similaires.

À défaut, un petit onduleur qui peut déclencher un arrêt normal sera probablement votre meilleur pari dans ce cas. S'appuyer sur les utilisateurs pour des choses comme ça demande d'échouer.

L'os sous-jacent doit garantir une écriture réussie ou une erreur est retournée. Le système d'exploitation s'appuie à son tour sur des pilotes qui, à leur tour, s'appuient sur un micrologiciel qui repose sur le matériel.

C'est pourquoi vous devez vérifier auprès du fabricant du pilote / micrologiciel / matériel.

De même, l'ordre d'écriture doit être garanti sur toutes les couches, ce qui doit également être vérifié.

Même les caches sauvegardés par batterie peuvent échouer, par exemple pendant les tempêtes de New York, certains centres de données n'étaient pas accessibles pendant des jours et les batteries seraient épuisées, ce qui pourrait perdre les écritures commutées

https://www.postgresql.org/docs/devel/static/wal-reliability.html

https://brad.livejournal.com/2116715.html

http://rhaas.blogspot.com/2010/10/wal-reliability.html?m=1

Pour développer les autres réponses:

Tout d'abord, essayez de retirer le SQL du chariot élévateur si possible. Pensez que la récupération après une perte de puissance est mauvaise, essayez de le faire après que l'ordinateur portable s'est écrasé de plus de 7000 livres. Avec des heures d'activité en entrepôt, non sauvegardées ...

Deuxièmement, un mécanisme permettant à l'ordinateur portable de procéder à un arrêt automatique après une durée x sur la batterie devrait de toute façon être en place.

Troisièmement, la connexion de l'ordinateur portable à une alimentation non commutée sur le chariot élévateur serait-elle une option? Assurez-vous de tenir compte des règles de sécurité (l'environnement peut exiger que tout soit désactivé avec la clé du chariot élévateur) et de la durée pendant laquelle le chariot élévateur reste entre les utilisations (en particulier le week-end et les jours fériés) pour éviter de décharger la batterie de la machine.