Probleme avec option stopat

Le
Brigitte
Bonjour,

Auriez-vous une idée?
Environnement :

-La base source est en SP3A et la base cible en SP4A
Apres avoir retoré un dump full, je digère tous les fichiers de tran
séquentiellement dans l'ordre chronologique avec la meme instruction
stopat="9h " tant que je ne recontre aucune erreur d'exéction de l'ordre
RESTORE LOG.

Tous les fichiers de tran sont digérés avec un code retour à succés jusqu'à
celui généré en date de 11h qui est digéré "a moitié" puisque en tout état de
cause, il contient la date stopat spécifiée en paramètre.

Ce n'est qu'ensuite que les autres fichiers de tran ne sont plus digérés
avec l'erreur :

[Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set
begins at LSN 79738000001181200001, which is too late to apply to the
database. An earlier log backup that includes LSN 79738000001112700002 can
be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
abnormally.


Enuite, je refais un restore log du dernier fichier tran en succes, donc
celui généré à 11h, avec l'option recovery et l'instuction stopat="11h" et
cette instrcution s'effectue correctement avec succes.

Comment expliquer qu'il faille digérer les fichiers de tran générés jusqu'à
11h alors qu'on souhaite avoirr une base en date de 9h

Est-ce du à une transaction ou à un rollback de transaction commencé avant
9h et se termine à 11h ?

Merci

Bonne journée

Brigitte
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
bruno reiter
Le #11857951
si tu as une complète à 23h
une log toutes les 2 heures de 0h à 22h

pour restorer avec stopat 9h
tu dois restorer :
la complète NORECOVERY
les logs de 0h, 2h, 4h, 6h, 8h NORECOVERY
le log de 10h stopat 9:00 RECOVERY

HTH

br

"Brigitte" news:
Bonjour,

Auriez-vous une idée?
Environnement :

-La base source est en SP3A et la base cible en SP4A
Apres avoir retoré un dump full, je digère tous les fichiers de tran
séquentiellement dans l'ordre chronologique avec la meme instruction
stopat="9h " tant que je ne recontre aucune erreur d'exéction de l'ordre
RESTORE LOG.

Tous les fichiers de tran sont digérés avec un code retour à succés
jusqu'à
celui généré en date de 11h qui est digéré "a moitié" puisque en tout état
de
cause, il contient la date stopat spécifiée en paramètre.

Ce n'est qu'ensuite que les autres fichiers de tran ne sont plus digérés
avec l'erreur :

[Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set
begins at LSN 79738000001181200001, which is too late to apply to the
database. An earlier log backup that includes LSN 79738000001112700002 can
be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
abnormally.


Enuite, je refais un restore log du dernier fichier tran en succes, donc
celui généré à 11h, avec l'option recovery et l'instuction stopat="11h" et
cette instrcution s'effectue correctement avec succes.

Comment expliquer qu'il faille digérer les fichiers de tran générés
jusqu'à
11h alors qu'on souhaite avoirr une base en date de 9h

Est-ce du à une transaction ou à un rollback de transaction commencé avant
9h et se termine à 11h ?

Merci

Bonne journée

Brigitte



Fred BROUARD
Le #11857941
Brigitte a écrit :
Bonjour,

Auriez-vous une idée?



Oui, je crois comprendre que vous voulez :
restaurer votre base de données jusqu'à 9h puis continuer a en ajouter
après celui contenant le STOPAT....
Si c'est ce que vous tentez de faire, c'est normal ! Cela s'apelle le
paradoxe temporel.

Si vous dite STOPAT 9h alors plus rien ne peut être ajouté à votre
restauration. D'ou le message.

me trompe je ?

31 question depuis juin 2006.... Je me demande si vous n'auriez pas
intérêt à faire une bonne formation, parce que là vous perdez du temps
et votre entreprise de l'argent !

A +



Environnement :

-La base source est en SP3A et la base cible en SP4A
Apres avoir retoré un dump full, je digère tous les fichiers de tran
séquentiellement dans l'ordre chronologique avec la meme instruction
stopat="9h " tant que je ne recontre aucune erreur d'exéction de l'ordre
RESTORE LOG.

Tous les fichiers de tran sont digérés avec un code retour à succés jusqu'à
celui généré en date de 11h qui est digéré "a moitié" puisque en tout état de
cause, il contient la date stopat spécifiée en paramètre.

Ce n'est qu'ensuite que les autres fichiers de tran ne sont plus digérés
avec l'erreur :

[Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set
begins at LSN 79738000001181200001, which is too late to apply to the
database. An earlier log backup that includes LSN 79738000001112700002 can
be restored.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
abnormally.


Enuite, je refais un restore log du dernier fichier tran en succes, donc
celui généré à 11h, avec l'option recovery et l'instuction stopat="11h" et
cette instrcution s'effectue correctement avec succes.

Comment expliquer qu'il faille digérer les fichiers de tran générés jusqu'à
11h alors qu'on souhaite avoirr une base en date de 9h

Est-ce du à une transaction ou à un rollback de transaction commencé avant
9h et se termine à 11h ?

Merci

Bonne journée

Brigitte





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Brigitte
Le #11857821
Bonjour,

Merci pour votre réponse mais en fait je transfère souvent les questions de
collègues.
En fait, vous n'avez pas compris sa question ou peut-être n'était-elle pas
assez claire.
Je lui ai trouvé la solution à son problème.

Cordialement

Brigitte

"Fred BROUARD" a écrit :

Brigitte a écrit :
> Bonjour,
>
> Auriez-vous une idée?

Oui, je crois comprendre que vous voulez :
restaurer votre base de données jusqu'à 9h puis continuer a en ajouter
après celui contenant le STOPAT....
Si c'est ce que vous tentez de faire, c'est normal ! Cela s'apelle le
paradoxe temporel.

Si vous dite STOPAT 9h alors plus rien ne peut être ajouté à votre
restauration. D'ou le message.

me trompe je ?

31 question depuis juin 2006.... Je me demande si vous n'auriez pas
intérêt à faire une bonne formation, parce que là vous perdez du temps
et votre entreprise de l'argent !

A +



> Environnement :
>
> -La base source est en SP3A et la base cible en SP4A
> Apres avoir retoré un dump full, je digère tous les fichiers de tran
> séquentiellement dans l'ordre chronologique avec la meme instruction
> stopat="9h " tant que je ne recontre aucune erreur d'exéction de l'ordre
> RESTORE LOG.
>
> Tous les fichiers de tran sont digérés avec un code retour à succés jusqu'à
> celui généré en date de 11h qui est digéré "a moitié" puisque en tout état de
> cause, il contient la date stopat spécifiée en paramètre.
>
> Ce n'est qu'ensuite que les autres fichiers de tran ne sont plus digérés
> avec l'erreur :
>
> [Microsoft][ODBC SQL Server Driver][SQL Server]The log in this backup set
> begins at LSN 79738000001181200001, which is too late to apply to the
> database. An earlier log backup that includes LSN 79738000001112700002 can
> be restored.
> [Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
> abnormally.
>
>
> Enuite, je refais un restore log du dernier fichier tran en succes, donc
> celui généré à 11h, avec l'option recovery et l'instuction stopat="11h" et
> cette instrcution s'effectue correctement avec succes.
>
> Comment expliquer qu'il faille digérer les fichiers de tran générés jusqu'à
> 11h alors qu'on souhaite avoirr une base en date de 9h
>
> Est-ce du à une transaction ou à un rollback de transaction commencé avant
> 9h et se termine à 11h ?
>
> Merci
>
> Bonne journée
>
> Brigitte
>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************



Publicité
Poster une réponse
Anonyme