Restore long en progress

Version imprimable

14/10/2018, 17h34
Trady

Restore long en progress

Bonjour,

J'ai un souci avec le RESTORE d'une base qui est depuis plus de 15h sur 100% mais toujours en état "progress".

Voici les détails de cette base

Mybase.bak 3,117,000 KB
Mode FULL recovery

et les fichiers qui sont créés

C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA

Mybase.mdf = 33,554,432 KB
Mybase_1.mdf = 33,554,432 KB
Mybase_2.mdf = 33,554,432 KB
Mybase_3.mdf = 33,554,432 KB

Et sur D:\sqldata

Mybase_log.ldf = 134,217,728 KB

Un backup complet avait lieu tous les matins une fois par jour.
Et des backup LOG toutes les 15mn. Je n'ai à réinstaller que le full .bak

J'ai dimensionné de la même façon que la base en production, suivant cet exemple :
https://www.developpez.net/forums/d1...a/#post8127406

Je n'ai plus accès à cette base en production, j'ai donc uniquement ce .bak, et à restaurer sur un autre serveur.
L'unique solution est-elle d'attendre la fin du restore ? si il y a une fin ? Quelle durée max approximative ?

Merci par avance de vos avis sur ce point.

Cordialement,
14/10/2018, 18h10
SQLpro

cela n'est pas anormal s'il y a eu de longues et importantes transactions.
En effet le processus de restauration est le suivant :
1) création des fichiers
2) formatage des fichiers (sauf pour les fichiers de données si "Instant File Initialization" a été mis en œuvre)
3) copie des pages binaires de la sauvegarde dans les fichiers de données
4) phase de "recovery" qui consiste à rejouer les dernières transactions

C'est cette dernière phase qui se joue actuellement sur votre serveur. Elle peut être plus ou moins longue en fonction :
1) de la volumétrie des transaction
2) de la RAM du serveur de destination (moins il y en a plus ce sera long)
3) de la conception du stockage (le nombre de VLF du JT ayant une forte influence à ce moment

Si vous combinez peu de RAM et de n'avoir pas gérer votre stockage sur la base, alors cette phase peut être très longue !

A +
14/10/2018, 18h27
Trady

Merci SQLpro, donc à partir du moment où le progress "tourne" c'est que c'est bien toujours en cours (message erreur sinon) ? Car je craignais que ça soit sans fin en fait et inutile d'attendre +.
Une idée d'un maximum d'attente ? pas en semaine au moins ?

PS: il y a de la RAM 128go et le stockage était basé sur votre exemple (mais peut-être une erreur quelque part, enfin probablement si c'est aussi long).
15/10/2018, 09h18
SQLpro

est-ce terminé ?

Je soupçonne une transaction longue non terminée....

A +
15/10/2018, 09h33
mikedavem

Ou un nombre de VLFs important (fichier journal très fragmenté ) comme tu le mentionnes précédemment ... déjà vu une restauration prendre plus d'une journée avec des milliers de VLFs.

++
15/10/2018, 11h05
Trady

Bonjour à vous,

Oui ça tourne toujours en progress.

Sinon j'ai avancé en amont: j'ai réussi à récupérer les 4 fichiers .mdf du serveur original sur un serveur tiers (tous ces serveurs sont distants, pas facile car le support de l'hébergeur n'est pas très coopératif).
Ils ont connecté les 2 anciens disques en USB sur ce serveur tiers de secours (récupération avec TestDisk).
Je vais essayer maintenant de récupérer le .ldf qui était sur le 2e disque.

Je vois ici qu'il est possible normalement de reprendre une base qui n'a pas été détachée :
https://www.experts-exchange.com/art...-Detached.html

Si je récupère bien l'accès à la base originale, je peux passer directement en mode RECOVERY SIMPLE et faire un backup général ? Ou dois-je modifier autre chose pour ce souci de VLF ?

a+
15/10/2018, 11h29
Boubou2020

Ou dois-je modifier autre chose pour ce souci de VLF ?

il faut faire du shrink log

Merci, d'accord donc :

Code:

1
2
3
4
5
6
7
8
9
USE AdventureWorks2012;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE AdventureWorks2012  
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 1 MB.  
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);  
GO

et laisser en SIMPLE.

15/10/2018, 14h04
SQLpro

Citation:

Envoyé par abdallah_mehdoini

Ou dois-je modifier autre chose pour ce souci de VLF ?

il faut faire du shrink log

Non, ça c'est pas suffisant. Il faut le dimensionner correctement après l'avoir diminué par SHRINK. Le mieux étant de :
1) passer en mode simple le journal
2) mettre la base en utilisateur unique en restant dedans
3) faire un CHECKPOINT
4) diminuer le JT le plus possible
5) créer un nouveau fichier correctement dimensionné (environ 20 % de la taille des données)
6) fixer l'ancien fichier du journal à la taille actuelle.

A +
15/10/2018, 14h49
Trady

Ah j'ai agit avant de voir votre dernier message SQLpro.

Bon je parviens bien maintenant à restaurer directement et très rapidement sur le nouveau serveur.

J'ai laissé en mode simple. Je vais me pencher dès que possible sur la vérification de la config et dimensionnement.

Merci à vous
15/10/2018, 15h35
SQLpro

Même en mode simple, il vous reste le 5 et 6 à faire.

A +
15/10/2018, 19h58
Trady
J'aurai bien relu ces points dans votre livre, mais ma femme ne m'a laissé le droit de le prendre dans les valises :mrgreen: (trop gros) et je ne suis pas de retour en France avant 1 mois.

Le fichier MyBase_log.ldf est maintenant de 52,224 KB.

Vous dîtes donc de créer dans un 1er temps un nouveau fichier MyBase_v2_log.ldf ? ou voulez-vous dire de modifier l'existant, par exemple ainsi :
Code:

1 2 3 4 5 ALTER DATABASE [MyBase] MODIFY FILE (NAME = 'MyBase_log', SIZE = 52224 KB, FILEGROWTH = 20%)
17/10/2018, 10h29
Trady

Update sur mon souci de restauration: en fait, il s'agissait d'un problème de disque défectueux sur le nouveau serveur (testé avec HD Sentinel) !