SQL Server - Les horodatages des fichiers sont inchangés, alors qu'est-ce qui est sauvegardé?
Veuillez voir l'instantané ci-dessous, montrant les horodatages de tous les fichiers de données ainsi que les fichiers journaux des transactions pour l'une des instances SQL Server sous ma gestion. Il s'agit d'une instance de production.
Aujourd'hui est le 27 décembre 2019. Cependant, comme vous pouvez le voir, tous les horodatages affichent des temps beaucoup plus anciens.
La vérité est que j'ai pris cet instantané il y a quelques jours - le 24 décembre, pour être exact. Cependant, comme je l'ai vérifié aujourd'hui, la situation est toujours inchangée.
L'instantané ci-dessus a été tiré des bases de données utilisateur. J'ai vérifié les bases de données système qui résident dans un dossier séparé sur un lecteur séparé, et pour elles, la situation était légèrement différente:
Maintenant, ces bases de données ne sont certainement pas super actives. Mais, je suis certain qu'il y a des transactions en cours tout le temps. En outre, j'ai regardé le rapport "Historique des changements de schéma" pour quelques-uns d'entre eux, et j'ai confirmé que nos travaux de maintenance avaient reconstruit les index aussi récemment qu'hier - 26 décembre.
Les bases de données sont toutes dans le modèle de récupération complète (bien que cela ne soit pas pertinent - peu importe que ce soit juste un fait). Le système d'exploitation est Windows NT 6.0 (c'est-à-dire Windows Server 2007) et la version SQL Server est 2008 SP3. Le système d'exploitation et SQL Serve doivent être mis à niveau l'an prochain au premier trimestre. De plus, la configuration sur ce serveur dont j'ai hérité n'est pas la meilleure, avec des fichiers de données et des fichiers journaux résidant dans le même dossier. Donc, j'espère que tout sera corrigé pendant l'activité de mise à niveau/migration dans quelques mois.
Maintenant, la question est pour moi, pourquoi malgré des transactions, ces fichiers ne changent pas? Même moi, j'ai exécuté manuellement "Checkpoint" mais cela n'a rien changé. Alors, pourquoi ça? puis, SI les fichiers journaux des transactions ne changent pas, mes sauvegardes sont-elles bonnes? Contiennent-ils vraiment ce qu'ils sont censés contenir?
ou est-ce que je manque quelque chose, peut-être à cause du vieillissement? :)
En réponse à votre question principale ("ce qui est sauvegardé"), tout ce qui est censé être ???? Plus sérieusement, vous ne pouvez pas utiliser ces horodatages comme signe de changements qui se produisent dans les fichiers de base de données. SQL Server ne fait aucune garantie sur la façon dont la date de modification des fichiers de base de données sera changée ou mise à jour.
Il y a un article de blog intéressant ici qui tente de trouver des modèles avec quand et comment le timbre de date modifié est mis à jour sur les fichiers MDF:
Fichier de base de données SQL Server - Date de modification
Leurs observations concordent avec votre situation, je pense: les écritures normales dans le fichier de données ne mettent pas à jour le tampon de date modifié. Il semble que les événements de croissance (manuels ou automatiques) mettent à jour cette valeur, tout comme le redémarrage du service (ou toute autre chose qui pourrait "ouvrir" ou "fermer" une base de données - en utilisant la fonction de fermeture automatique, en mettant explicitement la base de données hors ligne, etc.).
Je m'attends à 19/12/2019 9:52 PM correspond à un redémarrage de Windows ou SQL Server, c'est ainsi que plusieurs des dates/heures ont été synchronisées.
Cependant, encore une fois, ce comportement n'est pas documenté. Tous les modèles que nous remarquons pourraient changer à tout moment, ou avoir des cas Edge inattendus.
Pour les fichiers de données SQL Server résidant sur un système de fichiers NTFS, this s'applique:
La seule garantie concernant l'horodatage d'un fichier est que l'heure du fichier est correctement reflétée lorsque le handle qui effectue la modification est fermé.
Bien, pour être clair, c'est une garantie fournie par Windows. Nous ne pouvons pas nécessairement en savoir beaucoup sur la façon dont SQL Server crée et détruit les descripteurs de fichiers dans chaque scénario.
David Browne (un Top Microsoft Man) l'a mentionné dans un commentaire, ce qui est utile de savoir:
SQL Server garde les fichiers de base de données ouverts à chaque exécution, pour de meilleures performances et une protection contre les autres processus qui les modifient. Les attributs ne sont donc pas modifiés à chaque écriture de fichier.