> Tech > Reprise dans SQL Server 2000 vs. 7.0

Reprise dans SQL Server 2000 vs. 7.0

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

Si vous êtes dans l'obligation de récupérer une base de données rendue inutilisable par la défaillance d'un lecteur, vous souhaiterez probablement restaurer le maximum de transactions terminées avant la défaillance. SQL Server Books Online (BOL) dit que si le fichier journal est encore disponible (c'est-à -dire, si le disque endommagé n'est

pas celui qui contenait le journal),
vous devriez pouvoir sauvegarder les enregistrements de journal enregistrés depuis la dernière sauvegarde de journal régulière.
Toutefois, SQL Server 7.0 exige que le fichier de données primaire soit aussi disponible. Le fichier de données primaire
contient les informations sur l’emplacement du fichier journal, et, si le fichier de données primaire se trouvait sur l’un des lecteurs
endommagés, le journal ne sera pas utilisable pour la sauvegarde. Dans SQL Server 2000, Microsoft a corrigé ce problème.
Les informations à  propos de l’emplacement du fichier journal physique sont désormais stockées de manière redondante
dans la base de données maîtresse, donc même si le fichier de données primaire d’une base de données est indisponible,
un administrateur peut sauvegarder la portion du journal qui contient l’enregistrement des transactions jusqu’au moment de
la défaillance de la base de données. Cette sauvegarde de journal finale est la dernière que vous restaurerez pour redonner à 
la base de données son état précédent.

Téléchargez cette ressource

Guide de Threat Intelligence contextuelle

Guide de Threat Intelligence contextuelle

Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique

Les plus consultés sur iTPro.fr

A lire aussi sur le site

À la une de la chaîne Tech