SelectEtoile : Base de connaissance SGBD

Posts Tagged 'sysdatabases'

Comment récupérer une base à partir du fichier mdf ?

1 Faire une copie des fichiers encore présents de la base de données.
2 Procéder à la création d'une nouvelle base de donnée
Elle devra porter les mêmes noms de fichiers ( .MDF et .LDF) que l'ancienne
3 Stopper le service SQLServer
4 Détruire les fichiers de la base nouvellement créée.
5 Renommer les premiers fichiers de base pour qu'ils correspondent à ceux de la base précédemment créée
6 Redémarrer le service SQLServer.
A ce stade la base de données devrait être active et fonctionner.
Si par contre, elle apparaît en suspect il ne faut pas s'inquiéter. Il faut procéder aux étapes suivantes.
7 Avec l'analyseur de requêtes, se connecter sur le serveur sur la base master et effectuer les commandes suivantes

sp_configure 'allow updates',1
reconfigure with override
UPDATE sysdatabases SET status=32768 WHERE name='bdName'

8 Stopper le service SQLServer.
9 Renommer le fichier Log en .old (ou toute autre extension)
10 Redémarrer le service SQLServer. ( Si ce n'était pas déjà le cas, la base apparaît en 'suspect')
11 DBCC rebuild_log ('bdName','chemin complet et nom du fichier log à reconstruire')
12 UPDATE sysdatabases SET status=0 WHERE name='bdName'
13 Puis pour finir

DBCC checkdb ('bdName ')
GO
DBCC newalloc ('bdName ')
GO
DBCC checkcatalog ('bdName ')
GO

Ceci pour vérifier la cohérence de la base de données

Rechargement base avec modification status

Cet article décrit la procédure pour recharger une base qui est soit suspect, soit dans un état "impossible à loader"

 

Sauvegarde du status de la base

select status from sysdatabase where name = "MABASE"

A garder bien soigneusement

 

Mise à jour du status de la base pour reload :

1> begin tran

2> go

1> update sysdatabase set status = RefStatus where name = "mabase"   -- Refstatus défini ci dessous

2> go

1> commit

2> go

1> shutdown -- ou shutdown with nowait si nécessaire

2> go

 

RefStatus :

  • -32768 en cas de base en état 'suspect' (après le reboot, il faudra supprimer la base et la reconstruire)
  • 32 met la base en état 'à loader' (après reboot, il suffira de recharger la base)

 

Si on a mis le status à -32768 :

Extraire l'ordre de création de la base (create database mabase for load ...)

1> dbcc dbrepair('mabase','dropdb')

2> go

1> create database mabase for load

2> go

1> load database mabase ....

2> go

1> online database mabase

2> go

-- Vérification du status de la base mabase


Si on a mis le status à 32 :

 

  • Après le redémarrage, bien vérifier que la base mabase est dans l'état 'à recharger'.
  • Sinon, il faut redémarrer jusqu'à ce que ce soit le cas
  • Ensuite, on peut recharger la base

 

 

 

 

Error 3475 during recovery

Quand on détecte l'erreur 3475 dans l'errorlog durant le recovery d'une base, le serveur marquera cette base à 'not recovered' et la gardera offline (La base peut avoir le status 64 ou 68 dans sysdatabases)


Il est nécessaire de bypasser le recovery et d'augmenter le journal de transaction


Pour cela, suivre la procédure suivante :

- faire un update de la table sysdatabases et positionner le status de la base à -32768 (garder en mémoire la valeur de la colonne status avant modification)
- faire un 'checkpoint' sur la base master
- Lancer un 'shutdown with nowait'
- redémarrer le server (il ne va pas faire de recovery sur la base en question)
- Ajouter le ou les devices de logs
- Faire un update sur sysdatabases en remettant la valeur sauvegardée au début.
- Faire checkpoint in master
- Rebooter un derniere fois le serveur SYBASE.

Maintenant, le recovery devrait se faire sans problème.