Tout d'abord je m'excuse pour la longueur de ce post, mais je donne le
maximum d'info que j'ai en ma possession.
J'ai une sauvegarde d'une base de données (Promotool) qui apparemment pose
problème lors de la restauration.
J'ai l'erreur 42000 a la fin de l'opération de restore. Les fichiers MDF et
LOG ont bien été créé. La base a comme statut "suspect".
Dans le fichier LOG, j'ai :
spid9 Impossible d'associer les fichiers à différentes bases de
données.
spid9 Le fichier journal 'D:\MSSQL\Promotool_Log.LDF' ne correspond
pas au fichier primaire. Il provient peut-être d'une base de données
différente ou le journal a peut-être été reconstruit précédemment.
Si je fais un
dbcc checkdb ('Promotool')
Il me renvoi l'erreur :
La base de données 'Promotool' ne peut pas être ouverte car des fichiers
sont inaccessibles, la mémoire ou l'espace disque sont insuffisants. Pour
plus d'informations, consultez le journal des erreurs de SQL Server.
Si je change son statut pour passer en mode d'urgence, je peux me connecter
dessus et refaire un
dbcc checkdb ('Promotool')
Il me renvoi l'erreur :
Des erreurs de cohérence de la base de données 'Promotool' dans
sysobjects, sysindexes, syscolumns ou systypes empêche la suite CHECKDB du
traitement.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages
d'erreur, contactez l'administrateur du système.
J'ai donc décidé de faire un
use Promotool
dbcc checktable ('sysobjects')
J'obtiens alors l'erreur:
La page (1:207157), ID d'objet = 1, ID d'index = 3 a été modifiée mais
n'a pas été marquée comme telle dans la bitmap de sauvegarde différentielle.
Résultats DBCC pour 'sysobjects'.
Il y a 1587 lignes dans 30 pages pour l'objet 'sysobjects'.
CHECKTABLE a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence
dans la table 'sysobjects' (objet ID = 1).
repair_allow_data_loss est le minimum de niveau de réparation pour les
erreurs trouvés par DBCC CHECKTABLE (Promotool.dbo.sysobjects ).
Je passe en mode mono utilisateur sur la base Promotool pour effectuer un
repair_allow_data_loss.
dbcc checktable ('sysobjects', repair_allow_data_loss)
J'ai alors le message suivant :
Impossible d'exécuter BEGIN TRANSACTION dans la base de données
'Promotool' parce qu'elle est en mode récupération de contournement.
Je suppose que le mode de récupération de contournement est le mode
d'urgence (qui permet de contourner les controles fait par SQL Server au
lancement.).
Mon problème est que si je ne suis plus en mode d'urgence, il ne veut pas se
connecter a ma base.
Je n'ai pas besoin de l'ensemble des données qui sont sur cette base (elle
fait environ 3 Go), mais j'aimerais récupéré ce qui est encore valable à
l'intérieur de celle-ci. En mode d'urgence, je peux faire des SELECTs sur
certaines tables, certains me renvoi des erreurs, mais j'ai malgré tout pas
mal de données qui me sont renvoyées.
Quelqu'un à t'il une idée pour que SQL Server me supprime les data non
valide et que ma base soit à nouveau accessible?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Med Bouchenafa
Un dernier espoir !!! Fait une recherche internet sur "sp_fixindex" C'est une procedure non documentée qui permet d'intervenir sur les tables système corrompues
Bien cordialement Med Bouchenafa
"Alexis Leroy" a écrit :
Bonjour à tous!
Tout d'abord je m'excuse pour la longueur de ce post, mais je donne le maximum d'info que j'ai en ma possession.
J'ai une sauvegarde d'une base de données (Promotool) qui apparemment pose problème lors de la restauration. J'ai l'erreur 42000 a la fin de l'opération de restore. Les fichiers MDF et LOG ont bien été créé. La base a comme statut "suspect". Dans le fichier LOG, j'ai : spid9 Impossible d'associer les fichiers à différentes bases de données. spid9 Le fichier journal 'D:MSSQLPromotool_Log.LDF' ne correspond pas au fichier primaire. Il provient peut-être d'une base de données différente ou le journal a peut-être été reconstruit précédemment.
Si je fais un dbcc checkdb ('Promotool') Il me renvoi l'erreur : La base de données 'Promotool' ne peut pas être ouverte car des fichiers sont inaccessibles, la mémoire ou l'espace disque sont insuffisants. Pour plus d'informations, consultez le journal des erreurs de SQL Server.
Si je change son statut pour passer en mode d'urgence, je peux me connecter dessus et refaire un dbcc checkdb ('Promotool') Il me renvoi l'erreur : Des erreurs de cohérence de la base de données 'Promotool' dans sysobjects, sysindexes, syscolumns ou systypes empêche la suite CHECKDB du traitement. Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur du système.
J'ai donc décidé de faire un use Promotool dbcc checktable ('sysobjects') J'obtiens alors l'erreur: La page (1:207157), ID d'objet = 1, ID d'index = 3 a été modifiée mais n'a pas été marquée comme telle dans la bitmap de sauvegarde différentielle. Résultats DBCC pour 'sysobjects'. Il y a 1587 lignes dans 30 pages pour l'objet 'sysobjects'. CHECKTABLE a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence dans la table 'sysobjects' (objet ID = 1). repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKTABLE (Promotool.dbo.sysobjects ).
Je passe en mode mono utilisateur sur la base Promotool pour effectuer un repair_allow_data_loss. dbcc checktable ('sysobjects', repair_allow_data_loss) J'ai alors le message suivant : Impossible d'exécuter BEGIN TRANSACTION dans la base de données 'Promotool' parce qu'elle est en mode récupération de contournement.
Je suppose que le mode de récupération de contournement est le mode d'urgence (qui permet de contourner les controles fait par SQL Server au lancement.). Mon problème est que si je ne suis plus en mode d'urgence, il ne veut pas se connecter a ma base. Je n'ai pas besoin de l'ensemble des données qui sont sur cette base (elle fait environ 3 Go), mais j'aimerais récupéré ce qui est encore valable à l'intérieur de celle-ci. En mode d'urgence, je peux faire des SELECTs sur certaines tables, certains me renvoi des erreurs, mais j'ai malgré tout pas mal de données qui me sont renvoyées.
Quelqu'un à t'il une idée pour que SQL Server me supprime les data non valide et que ma base soit à nouveau accessible?
Merci pour tout,
Cordialement Alexis Leroy
Un dernier espoir !!!
Fait une recherche internet sur "sp_fixindex"
C'est une procedure non documentée qui permet d'intervenir sur les tables
système corrompues
Bien cordialement
Med Bouchenafa
"Alexis Leroy" a écrit :
Bonjour à tous!
Tout d'abord je m'excuse pour la longueur de ce post, mais je donne le
maximum d'info que j'ai en ma possession.
J'ai une sauvegarde d'une base de données (Promotool) qui apparemment pose
problème lors de la restauration.
J'ai l'erreur 42000 a la fin de l'opération de restore. Les fichiers MDF et
LOG ont bien été créé. La base a comme statut "suspect".
Dans le fichier LOG, j'ai :
spid9 Impossible d'associer les fichiers à différentes bases de
données.
spid9 Le fichier journal 'D:MSSQLPromotool_Log.LDF' ne correspond
pas au fichier primaire. Il provient peut-être d'une base de données
différente ou le journal a peut-être été reconstruit précédemment.
Si je fais un
dbcc checkdb ('Promotool')
Il me renvoi l'erreur :
La base de données 'Promotool' ne peut pas être ouverte car des fichiers
sont inaccessibles, la mémoire ou l'espace disque sont insuffisants. Pour
plus d'informations, consultez le journal des erreurs de SQL Server.
Si je change son statut pour passer en mode d'urgence, je peux me connecter
dessus et refaire un
dbcc checkdb ('Promotool')
Il me renvoi l'erreur :
Des erreurs de cohérence de la base de données 'Promotool' dans
sysobjects, sysindexes, syscolumns ou systypes empêche la suite CHECKDB du
traitement.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages
d'erreur, contactez l'administrateur du système.
J'ai donc décidé de faire un
use Promotool
dbcc checktable ('sysobjects')
J'obtiens alors l'erreur:
La page (1:207157), ID d'objet = 1, ID d'index = 3 a été modifiée mais
n'a pas été marquée comme telle dans la bitmap de sauvegarde différentielle.
Résultats DBCC pour 'sysobjects'.
Il y a 1587 lignes dans 30 pages pour l'objet 'sysobjects'.
CHECKTABLE a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence
dans la table 'sysobjects' (objet ID = 1).
repair_allow_data_loss est le minimum de niveau de réparation pour les
erreurs trouvés par DBCC CHECKTABLE (Promotool.dbo.sysobjects ).
Je passe en mode mono utilisateur sur la base Promotool pour effectuer un
repair_allow_data_loss.
dbcc checktable ('sysobjects', repair_allow_data_loss)
J'ai alors le message suivant :
Impossible d'exécuter BEGIN TRANSACTION dans la base de données
'Promotool' parce qu'elle est en mode récupération de contournement.
Je suppose que le mode de récupération de contournement est le mode
d'urgence (qui permet de contourner les controles fait par SQL Server au
lancement.).
Mon problème est que si je ne suis plus en mode d'urgence, il ne veut pas se
connecter a ma base.
Je n'ai pas besoin de l'ensemble des données qui sont sur cette base (elle
fait environ 3 Go), mais j'aimerais récupéré ce qui est encore valable à
l'intérieur de celle-ci. En mode d'urgence, je peux faire des SELECTs sur
certaines tables, certains me renvoi des erreurs, mais j'ai malgré tout pas
mal de données qui me sont renvoyées.
Quelqu'un à t'il une idée pour que SQL Server me supprime les data non
valide et que ma base soit à nouveau accessible?
Un dernier espoir !!! Fait une recherche internet sur "sp_fixindex" C'est une procedure non documentée qui permet d'intervenir sur les tables système corrompues
Bien cordialement Med Bouchenafa
"Alexis Leroy" a écrit :
Bonjour à tous!
Tout d'abord je m'excuse pour la longueur de ce post, mais je donne le maximum d'info que j'ai en ma possession.
J'ai une sauvegarde d'une base de données (Promotool) qui apparemment pose problème lors de la restauration. J'ai l'erreur 42000 a la fin de l'opération de restore. Les fichiers MDF et LOG ont bien été créé. La base a comme statut "suspect". Dans le fichier LOG, j'ai : spid9 Impossible d'associer les fichiers à différentes bases de données. spid9 Le fichier journal 'D:MSSQLPromotool_Log.LDF' ne correspond pas au fichier primaire. Il provient peut-être d'une base de données différente ou le journal a peut-être été reconstruit précédemment.
Si je fais un dbcc checkdb ('Promotool') Il me renvoi l'erreur : La base de données 'Promotool' ne peut pas être ouverte car des fichiers sont inaccessibles, la mémoire ou l'espace disque sont insuffisants. Pour plus d'informations, consultez le journal des erreurs de SQL Server.
Si je change son statut pour passer en mode d'urgence, je peux me connecter dessus et refaire un dbcc checkdb ('Promotool') Il me renvoi l'erreur : Des erreurs de cohérence de la base de données 'Promotool' dans sysobjects, sysindexes, syscolumns ou systypes empêche la suite CHECKDB du traitement. Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur du système.
J'ai donc décidé de faire un use Promotool dbcc checktable ('sysobjects') J'obtiens alors l'erreur: La page (1:207157), ID d'objet = 1, ID d'index = 3 a été modifiée mais n'a pas été marquée comme telle dans la bitmap de sauvegarde différentielle. Résultats DBCC pour 'sysobjects'. Il y a 1587 lignes dans 30 pages pour l'objet 'sysobjects'. CHECKTABLE a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence dans la table 'sysobjects' (objet ID = 1). repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés par DBCC CHECKTABLE (Promotool.dbo.sysobjects ).
Je passe en mode mono utilisateur sur la base Promotool pour effectuer un repair_allow_data_loss. dbcc checktable ('sysobjects', repair_allow_data_loss) J'ai alors le message suivant : Impossible d'exécuter BEGIN TRANSACTION dans la base de données 'Promotool' parce qu'elle est en mode récupération de contournement.
Je suppose que le mode de récupération de contournement est le mode d'urgence (qui permet de contourner les controles fait par SQL Server au lancement.). Mon problème est que si je ne suis plus en mode d'urgence, il ne veut pas se connecter a ma base. Je n'ai pas besoin de l'ensemble des données qui sont sur cette base (elle fait environ 3 Go), mais j'aimerais récupéré ce qui est encore valable à l'intérieur de celle-ci. En mode d'urgence, je peux faire des SELECTs sur certaines tables, certains me renvoi des erreurs, mais j'ai malgré tout pas mal de données qui me sont renvoyées.
Quelqu'un à t'il une idée pour que SQL Server me supprime les data non valide et que ma base soit à nouveau accessible?
