Discussion :

[peio87]

Bonjour ,
je souhaite "joindre" un fichier mdf et son fichier ldf mais je suis bloqué par l'absence des fichiers .ndf que je n'ai pas gardé.
lors de l'attachement le message est "fichier ndf introuvable" et l'attache ment échoue
puis je les recréer ?

y a t il une solution;
je ne suis pas un expert sql ,juste consultant fonctionnel sur un soft dont les data sont stockés en sql.

les données ne sont pas critiques mais j'aimerais restaurer cette base.

Merci


Peio87

[Blacknounou]

Bonjour,

Avez-vous essayé un backup/restore de votre base ?

@ +

[peio87]

Bonjour,
Non car je n ai pas le .bck .
I s agit d un transfert des données d un Pc vers un autre et l ancien Pc a été raz.seules les mdf ont été transférés .

[Invité]

I s agit d un transfert des données d un Pc vers un autre et l ancien Pc a été raz.seules les mdf ont été transférés .

En bref, vous êtes dans la merde.
Vous avez copié une partie des fichiers nécessaires à votre bd et vous avez tout supprimé le reste et même pas fait de sauvegarde.
Outre que c'est très amateur comme façon de faire, il aurait été « intéressant » de vous documenter comment copier une bd avant de vous essayer...
Là, vous avez définitivement perdu toutes les données de vos fichiers .ndf, donc même si vous réussissiez à repartir le bout de bd restant avec le fichier, ça risque d'être assez inutile car incomplet.

[peio87]

Le contenu des 2 fichiers ndf n a aucune valeure dans mon contexte ni le contenu du ldf d ailleurs .
Les tables et la structure qui m intéressent sont dans le mdf.
La question s adresse donc aux gens susçeptibles de savoir rattacher le mdf sans les ndf car ce dont j ai besoin est dedans et uniquement dedans ...
Merci de s en tenir au contexte décrit ,sans préjugé de ce qui a été mal fait ,par moi ou pas par moi...cela n a aucun intérêt .

[Boubou2020]

tu peux penser a cette utilitaire , peut être vous aurez besoin de licence
http://www.erepairsqlserver.com/

[Invité]

Le contenu des 2 fichiers ndf n a aucune valeure dans mon contexte ni le contenu du ldf d ailleurs .

Effectivement, si on met à part l'intégrité de la base de données...

[peio87]

tu peux penser a cette utilitaire , peut être vous aurez besoin de licence
http://www.erepairsqlserver.com/

Bonjour,
Merci pour votre réponse, c est une piste à explorer .

[elsuket]

Bonjour,

Le fichier du journal des transactions (ldf) est très important car il garantit l'intégrité de la base de données.

Vous dites que le contenu des ndf ne vous intéresse pas, ce qui signifie que vous les aviez placés dans un groupe de fichiers et créé les tables dans ce groupe de fichiers en isolation totale du reste de la base de données, c'est à dire au minimum sans contraintes d'intégrité; est-ce bien votre cas ?

Notez qu'une base de données relationnelle SQL n'est pas un simple ensemble de fichier dans lequelles des données sont écrites. Chaque fichier sert un but particulier, à commencer par l'intégrité des données. Pour avoir fait défaut à tous les fichiers de la base de données, vous en subissez malheureusement les conséquences.

Même si vous tentiez d'attacher la base de données seulement avec le mdf avec reconstruction du fichier du journal des transactions, cela ne fonctionnera pas (j'ai testé par abus de conscience). Donc comme le disait 7gyY9w1ZY6ySRgPeaefZ, votre base de données n'est pas récupérable dans l'état actuel.

La première chose à faire lorsqu'on crée une base de données ou qu'on prend en charge une instance d'un moteur de base de données, c'est de s'assurer que les bases de données sont correctement sauvegardées, notamment en pensant au plan de recouvrement d'activité.

@++

[peio87]

Bonjour,
Merci d'avoir prêté attention à ma question.
l'application métier qui a généré cette base avait sans doute une option "full text search" d'activée qui a généré ces fichiers ndf.Je pense qu'ils étaient destinés à contenir l'indéxation de certains champs sur certaines tables dans le cas ou le modèle de la base de données auraient été amendés par le framework applicatif ce qui n'a pas été le cas au final ou pour accélérer les perf de certaines requêtes.Donc soit ils étaient quasi vides soit ce qu'il contenait n'a aucun intérêt puisque les données métiers importantes sont dans le mdf.
le ldf ne me pose pas de problème, je l'ai.
ce sont ces fichiers ndf qui posent problème.


j'ai bien compris que SQL me réclame ce fichier ndf pour son intégrité à lui mais dont je n'ai pas besoin dans mon contexte
Ma question est purement technique :
peut-on, oui ou non rattacher les mdf et ldf sans les ndf qui me sont réclamés (sans préjugé de l'intégrité globale de la base au sens purement SQL , ce dont je ne me soucie pas dans ce contexte,seul le contenu du mdf à un sens dans le contexte métier et pour l'application métier utilisé pour lire son contenu):
-en désactivant une fonction ou un service.
-en regénérant un fichier ndf par la même application métier avec un nom identique de manière à faire un leurre... C'est la solution que j'envisage mais elle est couteuse pour moi en temps et en manipulation et je ne sais pas si ca marchera.
-avec une produre ou commande sql spéciale...
-autre.

L intégrité métier est assurée par l'application métier qui a besoin du mdf uniquement.
Ce ne sont pas des bases à exploiter réellement ;il n'y a donc pas de plan de sauvegarde à prévoir.
Cordialement.

Peio87

[elsuket]

Meri pour ces détails.

On peut tenter quelque chose de peu orthodoxe :

- Créer la base de données avec précisément le même nom, avec des nom de fichiers logiques et leur emplacement physique identiques à ce que vous aviez. On ferait ceci seulement pour le mdf et le ldf.
- Ensuite on met la base de données hors-ligne
- On remplace le fichier mdf par le fichier que vous avez
- On met la base de données en ligne et on prie pour que ça marche.

Je n'ai pas testé donc je ne peux pas vous garantir que cela fonctionnera.
Dites-nous si vous ne voyez pas comment exécuter cette liste d'opérations.

@++

[Invité]

Je n'ai pas testé donc je ne peux pas vous garantir que cela fonctionnera.
Dites-nous si vous ne voyez pas comment exécuter cette liste d'opérations.

J'avais testé avec une bd totalement vide mais avec la même configuration de fichiers et ça a planté :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Msg 5173, Level 16, State 2, Line 3
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files.  If this is an existing database, the file may be corrupted and should be restored from a backup.

Ça ne coûte rien d'essayer cependant.

[SQLpro]

Sans l'ensemble des fichiers, peut importe s'ils sont vide il n'ya a pas d'autres solution que de placer la base en mode d'urgence et de tenter un tail log backup, à condition que :

• vous soyez en mode de journalisation FULL
• vous ayez effectué au moins une sauvegarde complète préalable
• que vous ayez toutes les sauvegardes intermédiaires depuis cette complète

Dans ce cas vous pourrez tenter une restauration et vous retrouverez tous vos fichiers (y compris ceux que vous avez supprimé !).
C'est l'exercice type que je fais faire à mes stagiaires dans le cours d'admin de SQL Server à orsys !

A +

[peio87]

Meri pour ces détails.

On peut tenter quelque chose de peu orthodoxe :

- Créer la base de données avec précisément le même nom, avec des nom de fichiers logiques et leur emplacement physique identiques à ce que vous aviez. On ferait ceci seulement pour le mdf et le ldf.
- Ensuite on met la base de données hors-ligne
- On remplace le fichier mdf par le fichier que vous avez
- On met la base de données en ligne et on prie pour que ça marche.

Je n'ai pas testé donc je ne peux pas vous garantir que cela fonctionnera.
Dites-nous si vous ne voyez pas comment exécuter cette liste d'opérations.

@++

Bonjour
j'ai essayé votre méthode mais lorsque je me reconnecte dans la console la base est là mais elle n'est pas exploitable ,ni en mode suspect/récupération.

[peio87]

J'avais testé avec une bd totalement vide mais avec la même configuration de fichiers et ça a planté :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Msg 5173, Level 16, State 2, Line 3
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files.  If this is an existing database, the file may be corrupted and should be restored from a backup.

Ça ne coûte rien d'essayer cependant.

j'ai essayé cela aussi et en effet j'ai le même message.

[peio87]

Sans l'ensemble des fichiers, peut importe s'ils sont vide il n'ya a pas d'autres solution que de placer la base en mode d'urgence et de tenter un tail log backup, à condition que :

• vous soyez en mode de journalisation FULL
• vous ayez effectué au moins une sauvegarde complète préalable
• que vous ayez toutes les sauvegardes intermédiaires depuis cette complète

Dans ce cas vous pourrez tenter une restauration et vous retrouverez tous vos fichiers (y compris ceux que vous avez supprimé !).
C'est l'exercice type que je fais faire à mes stagiaires dans le cours d'admin de SQL Server à orsys !

A +

je n'ai pas de back up, juste le mdf et le ldf.
Comment placer la base en mode urgence tant que je ne l'ai pas rattaché?

[peio87]

j'ai trouvé cette manipulation qui s'apparente à ce que vous m'avez proposé mais le résultat est le même la base est visible dans sql (pas les tables) mais je ne peux rien faire dessus et elle n'est pas suspect ni en mode récupération.
Je ne sais pas écrire de script sql mes actions se limitent à l interface graphique de la console.

Procédure trouvé sur un forum ancien et pour du sql 7/2000
http://www.sqlservercentral.com/Foru...65155-5-1.aspx

jusqu'au point h) ca va mais aprés ,le script ne donne rien

Are you sure that you have got all data files from the original db? Are you sure that your .mdf and .ldf files come from the same db? If the latter is not true, you can try attach only mdf file and new log will be created for you by sql server. If a datafile(s) is missing you should get a complete set of files and start again. If it's not possible you can try these steps to salvage your data:

.

we've got only primary data file, all secondary files and log files are lost
sp_attach_db doesn't work because it looks for all files that originally comprised db
a) backup the file before going any further
b) rename the file to filename_old
c) create new db that has one file of the same physical name and size as our file
(logical name of the file and name of db can be different from original)
d) stop Sql server
e) replace original file for mdf file of newly created db
f) start SQL server
g) in SQL Server logs are messages 'Log file does not match the primary file.',
'Cannot associate files with different databases.' and db is suspect
h) Set database in emergency mode:

sp_configure 'allow updates', 1
reconfigure with override
go
update sysdatabases
set status = 32768
where name = 'db_name'
go
sp_configure 'allow updates', 0
reconfigure with override
go
i) Now Data should by accessible - Export data out of the database using bcp or DTS
j) drop db created in step c

[SQLpro]

Il y a de toutes façons très peu de chances, sans sauvegarde, que vous récupériez quoi que ce soit.
En effet une base de données c'est pas des fichiers à prendre à la légère et à tripoter comme ça en rigolant !
Il faut avoir un minimum de formation.

Désolé, mais là il faudrait avoir affaire à un expert et aucun ne peut garantir la récupération de la base.

Votre aventure résume à elle seule toutes les mauvaises pratiques :
1) aucune formation d'admin SQL Server
2) pas de sauvegardes
3) pas de sécurité SQL empêchant tout un chacun de faire n'importe quoi (privilèges SQL)
4) pas de sécurité au niveau Windows pour empêcher qui que ce soit de dézinguer des fichiers (droits systèmes)
5) on bricole les fichiers de la base en pensant que ça n'a aucune importance !
... et j'en passe !

Bref, si j'étais votre patron, je vous aurais flanqué à la porte


A +

[peio87]

non mais j'hallucine....De quoi je me mêle?!
C'est votre statut auto proclamé d'expert qui vous donne autant d'arrogance ?!Alors je suis bien content de ne pas être expert et bien content d'être un généraliste dans mon métier.
Les base de données ne seraient que des fichiers inutiles si il n'y avait pas des généralistes comme moi pour y installer des applications et leur trouver une utilité en les remplissant de données qui ont un sens!! je vais vous apprendre quelque chose Monsieur l'expert:
les entreprises n'invistissent pas des milliers d'euro dans des serveurs ,des SGBDR et des admnistrateurs pour le plaisir de voir fonctionner tout ce petit monde dans les règles de l'art !Les SGBDR ne sont pas une fin en soi mais un outil pour faire "fonctionner" leur business!!
En inscrivant sur ce forum j'étais loin de penser rencontrer un "spécialiste-pro- expert' dont 80% de son discours consiste à émettre des jugements de valeur sur un contexte qu'il ignore et pour lequel on ne lui demande rien et finalement assez peu utile pour résorber les vrais problèmes qui leurs sont soumis et dont la solution n'est pas dans la doc!
Mais bon vous être un prof tout s'explique.
....Votre réaction est typique de ce qu'on rencontre tellement dans les DSI des entreprises de nos jours :des spécialistes jargonneux incapable de contourner une problématique si c'est pas dans le manuel !.SI ce sont des gens comme vous qui les forme je comprends mieux!
[
Bref si j'étais votre patron je vous renverrai en formation !
Pour finir ,les 5 point que vous énumérez comme des bonnes pratiques le sont dans le contexte d'une installation faite pour une architecture de production chez un client qui paye (chere) un "administrateur de bdd pro -expert-spécialiste- SQL",mais inutile 95% du temps ....mais ce n' est pas mon contexte !!!!
et ces 5 points sont donc hors sujet dans mon contexte , qui est de restaurer ,suite au crash d'un pcportable , ce qui a pu être récupérer , pour installer cette bd sur un nouveau portable qui m'est fort utile à moi et rien qu'à moi .
Inutile de fantasmer un contexte,B]si vous n'avez pas de solution à proposer : n intervenez pas ![/B]
Merci de ne plus intervenir sur ce post et d'aller énumérer les bonnnes pratiques ailleurs.
A ce tarif je vais moi aussi pouvoir aider beaucoup de monde ici il me suffira de les copier/coller ca doit expliquer 95% des problèmes rencontrés.

[StringBuilder]

Ouais enfin, le monsieur expert en question, c'est lui qui les écrit les manuels hein...

Mais bon, trêve de plaisanterie.

Pas de doigts, pas de chocolat.
Pas de NDF, pas de base de données.

Point, et ça, c'est pas une plaisanterie, c'est un fait.

Reste donc la solution de récupération des données effacées sur le disque. Un outil tel que Recuva devrait permettre de retrouver les NDF manquants, surtout s'ils sont vides (et donc petits).

Il y a d'autres outils bien plus puissants, mais aussi bien plus chers (la version gratuite devrait suffire avec un peu de chance).

Tout ce qu'on peut espérer de cette expérience, c'est que vous mettrez en place des plans de backup y compris sur les postes utilisateurs (puisque visiblement, c'est de ça qu'il s'agit).