Discussion :

[alkimos]

Bonjour,

J'utilise une base de données SQL Server 2000. Il y a quelques jours j'ai remarqué que le backup journalier des données plantait depuis des semaines pour cause d'espace disque insuffisant. L'admin a réagi en faisant un shrink sur le journal des transactions pour libérer de l'espace disque ...
Enfin le soir même le backup a eu lieu sans problème.
Depuis de l'espace disque a été rajouté.

Mais j'ai remarqué quelque chose que je ne comprends pas :
- le journal des transactions (.LDF) n'a pas été modifié depuis le 21/01/08
- le fichier de données (.MDF) n'a pas été modifié depuis 06/01/08
alors que des centaines de milliers d'insert ou d'update sont faits chaque jour sans qu'il y ait de problème (j'ai vérifié les tables).
J'ai aussi vérifié via l'enterprise manager et les propriétés de la base que je regardais bien les bons fichiers LDF et MDF.
Pour info ces fichiers sont tous les 2 en croissance automatique et illimitée.
Il me semble que ces fichiers devraient être modifiés tout le temps vu l'activité de la base. Il faut croire que je n'ai pas compris le fonctionnement de SQL Server sur ce plan-là.
Il n'y aucune trace d'erreurs dans le journal des erreurs SQL server ni dans le journal des évènements Windows.
Quelqu'un pourrait-il m'éclairer ? Est-ce que c'est normal ? Merci.

Alkimos.

[SQLpro]

- le journal des transactions (.LDF) n'a pas été modifié depuis le 21/01/08
- le fichier de données (.MDF) n'a pas été modifié depuis 06/01/08

étrange non ??? Et bien pas du tout !!!!

Un SGBDR n'est pas un système de fichier genre cobol...
Lorsque vous demarrez SQL Server, toutes les bases de données sont ouvertes et les fichiers correspondant ouvertes en lecture/écriture à l'usage exclusif de SQL Server... Tous ces fichiers deviennent donc inaccessible. Il ne sont jamais fermés, sauf action speciale d'administration : mise en OFF LINE de la base, détachement...

Il faut croire que je n'ai pas compris le fonctionnement de SQL Server sur ce plan-là.

Là je confirme... Sans doute n'avez vous pas l'habitude de ce qu'est un vrai SGBD client serveur... Et le plus beau, c'est que la sauvegarde peut s'opérer sans avoir besoin de fermer les fichiers. Et la cerise sur le gâteau, c'est que si vous démarrez votre sauvegarde à minuit et qu'elle se termine à 1h... Vous aurez quelle version de la base à votre avis ? La version de minuit ou de 1h !

Hé bien celle de 1h ! Il est fort le cochon !!!

Allez, puisque vous êtes curieux, offrez vous un petit stage d'admin SQL Server (à Orsys par exemple puisque Rudi et moi donnons les cours que nous avons montés là bas), vous allez en apprendre de belle comme le fait de séparer sur deux disques physiques différents les fichiers du JT et des données, réserver toujours au moins 30% d'espace libre sur les disques du serveur et s'interdire tout autre application ou service sur le PC serveur hébergeant SQL Server....

Pourquoi, pourquoi, pourquoi.... Résponses !

A +

[alkimos]

Merci bien pour votre réponse.

En effet, une formation ne me ferait pas de mal. Je n'ai effectivement pas l'habitude de travailler sur des bases, je suis plutôt un utilisateur. N'étant pas DBA, peu de chance que mon entreprise ne m'offre une telle formation.
Je m'interesse au fonctionnement de SQL Server car j'ai récupéré plusieurs projets qui utilisent des bases SQL Server et pas de DBA SQL Server sous la main :-(
En attendant mieux, je vais me contenter de trouver un bon bouquin sur le sujet (peut-être des suggestions ? :-)

[SQLpro]

Si vous pouvez trouver d'occasion le livre de Marc Israël Chez Eyrolles, c'est bien. C'était en v 2000, mais cela constitue un excellent tour de la chose.

A +

[alkimos]

Ok.
Merci pour l'info.