Ce qui ' s votre chemin #1 d’être prudent avec une base de données en direct ?

Question

Pour mon client j’ai occasionnellement fonctionnent dans leur base de données en direct afin de corriger un problème qu’ils ont créé eux-mêmes, ou afin de corriger des données incorrectes qui créés des bogues de mon produit. Tout comme un accès root Unix, il est juste dangereux. Quelles leçons je devrais apprendre avance ?

Quelle est la chose #1 que vous faire pour être prudents et opérant sur des données en temps réel ?

Answer 1

<pre><code></code><p>De cette façon, vous pouvez restaurer après une erreur.</p></pre>

Answer 2

Trois choses que j'ai appris à la dure au fil des années...

Tout d'abord, si vous êtes en train de faire des mises à jour ou suppressions dans les données en direct, premier à écrire une requête SELECT avec la clause where vous allez utiliser. Assurez-vous qu'il fonctionne. Assurez-vous que c'est correct. Puis ajouter la mise à JOUR/SUPPRIMER la déclaration de l'état de fonctionnement de la clause where.

Vous ne voulez jamais avoir

DELETE FROM Customers

assis dans votre analyseur de requêtes en attente pour vous d'écrire la clause where... frappez accidentellement "exécuter", et que vous en avez tué votre table Client. Oups.

Aussi, en fonction de votre plate-forme, découvrez comment faire un rapide n'dirty sauvegarde d'une table. Dans SQL Server 2005,

SELECT *
INTO CustomerBackup200810032034
FROM Customer

copie toutes les lignes de l'ensemble de la table Client dans une nouvelle table appelée CustomerBackup200810032034, et vous pouvez ensuite les supprimer une fois que vous avez fait vos mises à jour et fait en sorte que tout est OK. Si le pire se produit, c'est beaucoup plus facile de restaurer les données manquantes à partir de ce tableau que de tenter de restaurer la dernière sauvegarde de la nuit du disque ou de la bande.

Enfin, méfiez-vous des suppressions en cascade de se débarrasser de choses que vous n'avez pas l'intention de supprimer - pour vérifier vos tables de relations et de contraintes de clé avant de modifier quoi que ce soit.

Answer 3

Faire une sauvegarde d’abord : il devrait être la loi numéro 1 de sysadmining quand même

EDIT: incorporant ce que d’autres ont dit, assurez-vous que vos mises à jour ont des clauses WHERE appropriées.

Idéalement, modifier une base de données active devrait jamais arriver (au-delà des encarts et entretien de base). Modification de structure de la DB direct pose surtout des éventuel mauvais karma.

Answer 4

Effectuez vos modifications dans une copie et lorsque vous êtes satisfait, puis appliquez le correctif à vivre.

Answer 5

Je le fais souvent avant une mise à jour ou supprimer, j’écris le SELECT équivalent.