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

[stdebordeau]

J'ai essayé la procedure décrite ici http://www.developpez.net/forums/d70...s-fichier-log/
mais ça ne marche pas. en fait j'avais en plus du fichier primaire, 4 autres fichiers pour mes indexs, et un fichier pour le journal des transactions. il ne me reste que le fichier primaire principal.

Je n'ai en fait pas besoin de récupérer les données, je peux les retrouver ailleurs. j'ai juste besoin de récupérer mes procédures

[janlouk]

Qu'avais-tu au départ ? Juste un fichier .mdf ? Ou aussi des .ndf ?

Qu'as-tu perdu ? Tout, ou que quelques DB ? Donne nous un peu plus de détail stp.

[stdebordeau]

j'avais en plus du mdf, 4 fichiers ndf pour des index et le fichier principal de transaction .ldf. il ne me reste que le fichier principal

[stdebordeau]

je viens d'essayer cet utilitaire http://www.erepairsqlserver.com/down...verInstall.exe
Il me répertorie effectivement tous mes objets, en particuliers mes procédures. Mais la récupération nécessite d’acquérir une licence.
Une autre alternative ?

[stdebordeau]

oups!! le lien précédent lance directement le téléchargement. Utiliser plutôt celui-ci
http://www.erepairsqlserver.com/
Désolé

[janlouk]

La plupart des softs de restore demandent une licence donc... Moi en tout cas je ne vois pas de solution autre qu'un soft dans ce genre vu que tu as "tout" supprimé.

A voir avec d'autres du forum s'ils ont une idée.

[Invité]

La plupart des softs de restore demandent une licence donc... Moi en tout cas je ne vois pas de solution autre qu'un soft dans ce genre vu que tu as "tout" supprimé.
A voir avec d'autres du forum s'ils ont une idée.

Pas mieux

[stdebordeau]

vu que je n'ai pas le choix je vais m'y résoudre. Avez vous un préféré en particulier.
En tout cas merci pour votre aide et ..........votre compassion

[mikedavem]

Hello,

Voici ce que tu peux tenter si tu as au moins ton fichier mdf:

- Créer une base de données avec un fichier mdf et un fichier ldf (tu donnes au minimum le même nom logique pour le fichier mdf)
- Tu mets ta base de données offline
- Tu remplaces le nouveau fichier mdf par ton fichier mdf sauvegardé
- Tu remets en ligne ta base de données ( ALTER DATABASE mabase SET ONLINE), ce qui devrait te provoquer des erreurs (manque des fichiers secondaires, fichier journal ne correspond pas au fichier mdf ...)
- Tu mets ta base de données en mode EMERGENY ( ALTER DATABASE mabase SET EMERGENCY). Tu ne devrais pas avoir d'erreur à ce moment là.
- Ta base de données est de nouveau accessible et tu peux récupérer tes objets

Tiens nous au courant

++

[stdebordeau]

Merci de l'idée, voici l'erreur que j'obtiens quand j'essai de dérouler le répertoire des procédures stockés


Impossible d'ouvrir FCB (File Control Block) pour l'ID de fichier non valide 3 dans la base de données «MaBD ». Vérifiez l'emplacement du fichier. Exécutez DBCC CHECKDB.
Une erreur grave s'est produite sur la commande actuelle. Les résultats éventuels doivent être ignorés. (Microsoft SQL Server, Erreur : 5180)

[stdebordeau]

après exécution de DBCC CHECKDB

Un ID de fichier inattendu a été trouvé. L'ID de fichier 8 était attendu, mais 2 a été lu dans "H:\MaBd_log.ldf". Vérifiez que les fichiers sont correctement mappés dans sys.master_files. ALTER DATABASE peut servir à corriger les mappages.
Échec de l'activation du fichier. Le nom de fichier physique "H:\MaBd_log.ldf" est peut-être incorrect.
Msg 5120, Niveau 16, État 5, Ligne 1
Impossible d'ouvrir le fichier physique "G:\MaBd_Index.ndf". Erreur du système d'exploitation 2 : "2(Le fichier spécifié est introuvable.)".
Msg 5120, Niveau 16, État 5, Ligne 1
Impossible d'ouvrir le fichier physique "E:\MaBd_Indexs.ndf". Erreur du système d'exploitation 2 : "2(Le fichier spécifié est introuvable.)".
Msg 5120, Niveau 16, État 5, Ligne 1
Impossible d'ouvrir le fichier physique "H:\MaBd_Index_1.ndf". Erreur du système d'exploitation 2 : "2(Le fichier spécifié est introuvable.)".
Msg 5120, Niveau 16, État 5, Ligne 1
Impossible d'ouvrir le fichier physique "H:\MaBd_Index_2.ndf". Erreur du système d'exploitation 2 : "2(Le fichier spécifié est introuvable.)".
Msg 5120, Niveau 16, État 5, Ligne 1
Impossible d'ouvrir le fichier physique "H:\MaBd_Index_3.ndf". Erreur du système d'exploitation 2 : "2(Le fichier spécifié est introuvable.)".
Msg 5028, Niveau 16, État 4, Ligne 1
Le système ne peut pas activer suffisamment la base de données pour reconstruire le journal.
Résultats DBCC pour 'MaBd'.
CHECKDB a trouvé 0 erreurs d'allocation et 0 erreurs de cohérence dans la base de données 'MaBd'.
Msg 7909, Niveau 20, État 1, Ligne 1
La réparation en mode d'urgence a échoué. Vous devez effectuer une restauration à partir d'une sauvegarde.

[Invité]

Au préalable fais des sauvegardes. Copie de tout ce qui reste !

Dans l'ordre,

1. Tu arrêtes l'instance.
2. Tu copies tous les fichiers dans un endroit sûr en backup.
3. Tu repars l'instance.
4. Tu supprimes ta bd qui semble s'appeler MaBd - beau choix ;-)
5. Tu recrées une bd MaBd en y ajoutant tous les fichiers telles qu'indiqués dans la liste - la bd sera vide, on est d'accord mais c'est ok.
6. Tu arrêtes l'instance.
7. Tu copies et remplaces le fichiers MaBd_log.mdf par celui qui te reste (mais tu en gardes une copie tout de même)
8. Tu redémarres l'instance et tu pries le dieu des agnostiques.
9. Tu regardes ce que ça donne dans la bd MaBd. Il est fort probable que tu aies une longue liste d'erreur dans les errorlogs mais peut-être que le code des procédures y sera lisible.

Je ne garantis rien, bien sûr, alors fait des copies avant !
J'imagine que le code est stocké dans le fichier .mdf par défaut, donc c'est à tester.

Ce truc là marche pour les fichiers log (.ldf) manquant, ça vaut le coup d'essayer ici avant de payer.

[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.