Bonjour..
quelle est la vraie fonctionnalité/explication de la mise 'hors ligne' d'une database ?
Bonjour..
quelle est la vraie fonctionnalité/explication de la mise 'hors ligne' d'une database ?
Vider la RAM de toutes les données et procédures mise en cache pour cette base, forcer les écritures des pages sales et interdire toute accès à la base.
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
MERCI...
J'ai une question sur un cas qui m'est arrivé hier...
Dans l'arborescence des databases, deux d'entre elles étaient arrétées (elles n'avaient pas de '+' devant et nous ne pouvions pas les ouvrir) => OK![]()
quand j'ai regardé le journal j'ai vu des erreurs de type :
J'ai recherché sur internet sans trouver vraiment la cause et, après moult recherche (et je n'aime pas faire ça !) j'ai décidé, via le clic droit de la database de la mettre 'hors ligne' et ensuite 'En ligne'...login failed for user TOTO (CLIENT : xxx.ddd.uuu.rrr) <= Adresse IP
erreur : 18456, gravité : 14, Etat :16 => OK![]()
Après cette opération de haute volée, la database a ensuite fonctionné normalement...
Donc ma database que je n'arrivais pas à ouvrir était dans un état entre le 'Hors ligne' et le 'En ligne'... était-elle en attente de restauration et le hors ligne rejoue t'il les logs ?
Avez-vous une explication à ça ?
Merci pour vos réponses
salut
il faudrait poster l'historique des logs du serveur pour vraiment comprendre cette histoire... fichiers ERRORLOG.xAvez-vous une explication à ça ?
Il n'y a pas de récupération des transactions lors de la mise en ligne de la base.était-elle en attente de restauration et le hors ligne rejoue t'il les logs ?
Dans SSMS, l'état est généralement indiqué à côté du nom de la bdd.
En sql :
Code : Sélectionner tout - Visualiser dans une fenêtre à part select databasepropertyex('mabase','status')
Quelle version de SQL Server ?
La base peut être inaccessible pour de multiples raisons. Elle peut être en cours de rechargement, au milieu du recovery, offline, suspect, etc...
Code : Sélectionner tout - Visualiser dans une fenêtre à part select name, state_desc from sys.databases
Merci à vous...
Version SQL Server => 2005
1) La prochaine fois je saurais detecter l'état de la database.. . qu'est-ce qu'un état 'suspect' ?
2) Comme dans Oracle, j'ai recherché le fichier log et je ne l'ai pas trouvé... pouvez-vous me dire où se trouve error.log et quelle différence a t'il avec les 'Journaux Sql Server' ?
Lorsque SQL Server redémarre suite à un arrêt volontaire ou non, les transactions qui étaient en cours au moment de l'arrêt peuvent être dans deux états différents: soit elles ont été validées mais les modifications n'ont pas eu le temps d'être écrites dans le fichier de données, soit les modifications ont été écrites en avance dans le fichier de données alors que la transaction n'était pas encore validée. Cette situation peut se produire car le mécanisme qui synchronise les données sur disque est complètement séparé de l'exécution des transactions.
Un état SUSPECT signifie que la récupération des transactions validées commence mais échoue au milieu en raison d'une erreur inattendue: corruption du journal de transaction ou corruption du fichier précisément sur une ou un ensemble de pages concernées par ces transactions à récupérer.
Le fichier ERRORLOG dont parle Emmanuel est l'équivalent de l'alert.log sur Oracle. Il se trouve par défaut sous le répertoire de l'instance dans le sous répertoire ~Log. Tu peux également consulter les ERRORLOG en transact-SQL en utilisant exec xp_readerrorlog n où n est le suffixe du fichier.
exec xp_readerrorlog -- (lira l'errorlog courant)
exec xp_readerrorlog 1 (lira ERRORLOG.1)
exec xp_readerrorlog 2 (lira ERRORLOG.2)
etc...
Partager