Discussion :

[stdebordeau]

Bonjour,
j'ai un gros soucis avec une base dont j'ai perdu le fichier journal (.ldf) et plusieurs autres fichiers primaires (.ndf) après certaines manipulations. J'ai essayé les différentes méthodes pour essayer de la joindre de nouveau à mon instance mais c'est assez problématique.

Actuellement, je veux juste récupérer les procédures stockés que j'y avais créé. Y'a t'il des possibilités?

D'avance merci pour vos contributions

[Invité]

C'est le moment de sortir les sauvegardes, non ?

[stdebordeau]

Pas de sauveagarde

[stdebordeau]

en fait c'est une nouvelle base dans laquelle j'avais développé bcp de procédures, mais pas sauvegardé parce que pas encore en production (ce n'est pas une raison, je sais).

[janlouk]

Pas de backup, les SP sont stockées dans les DB.

Et bien, j'espère que t'es motivé à les réécrire...

Que te reste-t-il ? Qu'as-tu essayé ? Tu as tout écrit directement dans SQL Server sans jamais garder une copie en local ?

[stdebordeau]

Bon Dieu !!! Dites moi qu'une solution existe.
Je n'ai aucune copie, nulle part

[hmira]

en fait c'est une nouvelle base dans laquelle j'avais développé bcp de procédures, mais pas sauvegardé parce que pas encore en production (ce n'est pas une raison, je sais).

Est-ce qu'on peut aussi, dans le cadre de cette discussion très révélatrice, rappeler que parmi les règles de bonnes pratiques, que personnellement j'ai toujours défendues et appliquées, est de faire en sorte que tous les scripts (scripts de création de tables, procédures, fonctions, triggers, contraintes, inserts des table paramétriques etc.. ) passent obligatoirement par un système de contrôle de version comme SubVersion (TortoiseSVN), Git ou TFS ou tout autre système.
Et la règle d'or stipule que c'est toujours le script versionné dans le repository qui fait foi, jamais le script extrait d'une quelconques base de développement.
En effet, les bases de développement sont généralement accessibles, et c'est normal, à tout une équipe de développeurs y compris les apprentis, les stagiaires, etc. et les fausses manipulations sous SSMS ne sont pas complètement exclues (click droit de la souris puis modifier ! voir même supprimer ! ), et par défaut, il n'y aucune traçabilité !

Personnellement, je ne fais aucune confiance à un script extrait d'une base de développement ou même extrait d'une base de production. En cas de problème ou "soupçon", je compare toujours le script extrait de la base avec le script du repository, et ce, avant d'envisager la suite, et le cas échéant apporter des correctifs en repassant d'abord par le circuit contrôle de version.

Donc, si vos scripts étaient sous contrôle de version, vous auriez pu aisément reconstituer les objets de la base (procédure, fonction, même la structure des tables etc..), dans une version donnée, depuis le repository de votre système de contrôle de version (CheckOut). Evidemment vous ne pourrez pas reconstituer toutes les données, mais les données d'une base de développement sont–elles vraiment vitales ? La réponse est généralement "Non".

Notez que même les sauvegardes régulières des bases de développement ne peuvent remplacer la rigueur d’un système de contrôle de version.

En ce qui concerne les données des bases clients. On n'a pas encore trouvé mieux que les sauvegardes vérifiées et testées , et en cas de pépin, situation extrêmement rarissimes sous SQL Server, procéder à une restauration de la base.

A+

[stdebordeau]

Bonjour à tous, merci pour votre intérêt.
J'ai finalement acquis la licence de eRepair SQL. J'ai pu récupérer juste 20% de mes procédures, c'est presque un échec.
J'ai déjà commencer a tout réécrire, mais comme on dit, la répétition est pédagogique.

Désormais donc, Plan de sauvegarde obligatoire pendant mes développement. J'explorerai les systèmes de contrôle de version proposés par hmira.


Je laisse le sujet ouvert un moment pour vous permettre de partager d'autres bonnes pratiques.