Discussion :

[korntex5]

bonjour, tout est dans le titre, comment faire pour bénéficier des bien faits du bakup/restore sur une base sans déconnecter mes utilisateurs, qui sont de plus en plus nombreux de nuit.

[SergioMaster]

Bonjour,

Backup : OUI , Restore : NON pour être aussi laconique que la question

[korntex5]

Le problème reste donc entier, durant le temps du bakup et du restore mes utilisateurs sont en lecture seule et je dois les couper au moment ou je remplace la production par le restore.

Ne peux-on pas éviter au moins le fait qu'ils soient en lecture seule via le ficher .delta, je m'explique:

1) Je met ma base en mode lock via nbakup et donc la génération du fichier .delta, afin que les utilisateurs puissent continuer de travailler.
2) Je lance mon GBAK sur le fichier de base de données pour faire un bakup
3) Je lance un restore de mon bakup toujours avec GBAK
4) Je coupe tous les utilisateurs
5) Je remplace le fichier de base de données par celui restauré (seul vrai temps d'indisponibilité réduit au simple temps de renommage des fichiers)
6) A ce moment les utilisateurs peuvent se reconnecter
7) Je déverrouille le Lock via NBAKUP sur ma nouvelle base.

Cela est-il viable?

[SergioMaster]

Bonjour,

A mon humble avis , si tu veux que les utilisateurs continuent de bosser , il faudrait prévoir une sorte de synchronisation des bases après le restore .
Temps d'attente = Resynchro + renommage fichier

la synchronisation est peut être la solution
1 -pause | peut être non nécessaire
2- passage en mode synchro } temps minime = activations des triggers
3- mode normal |
4- backup
5- restore dans autre fichier
6- pause
7- renommage
8- désactivation des triggers de synchro
9-synchronisation
10-mode normal

tout cela bien sur n'est qu'hypothèse , je connais pas bien nbackup et n'ai jamais été confronté à cette situation .
Peut être que nos amis anglo-saxons ont déjà une solution ?

[Edit]
Je reviens après avoir relu la doc sur nBackup . Si j'ai bien saisi , en fait nbackup ferait tout ça (synchro incluse c'est justement le fichier delta), sauf que nbackup ne fait pas le sweep ni ne controle les données ce que fait gbak (d'où sa rapidité ? ) http://www.firebirdsql.org/manual/fr...-overview.html (cette doc est-elle à jour ?)
mais le sweep ne pourrait-il se faire via gfix sans pénaliser les utilisateurs ? ou encore de manière automatique (sweep interval)

[makowski]

une base peut vivre sans jamais être restaurée, heureusement.
le sweep de temps en temps suffit.

[korntex5]

Tout à fait c'est le but de mon idée :
Faire un bakup via la commande NBAKUP et faire les plus du GBAK après à chaud. Mais je ne sais si les plus du GBAK sont uniquement le SWEEP ou si il y a autre chose...

[korntex5]

une base peut vivre sans jamais être restaurée, heureusement.
le sweep de temps en temps suffit.

bonne nouvelle mais alors pourquoi après mon sweep la taille du fichier de ma base de données ne diminue t-elle pas?

[makowski]

bonne nouvelle mais alors pourquoi après mon sweep la taille du fichier de ma base de données ne diminue t-elle pas?

Et pourquoi diminuerait elle ?

L'espace disque sera réutilisé, c'est tout, c'est même encore mieux, les pages seront disponibles, sans avoir besoin de demander de l'allocation d'espace au système de fichier.

[korntex5]

monsieur makowski, merci

vous modifiez grandement ma vision des choses...
Car nous effectuons des BAKUP/RESTORE pour récupérer de la place disque (car nous externalisons beaucoup de documents) et de plus la base de données nous semblait plus performante que suite au nbakup + sweep.

en résumé pour bien entretenir ma base et ses performances:

A) je peux quotidiennement:

1)Faire un NBACKUP pour sauvegarder ma base
2)Effectuer un SWEEP sur ma base de production
3)Recalculer mes index via "set statistics index"
4)Vérifier l'intégrité de ma base via "gfix -validate -full -no_update"

B) je peux 1 fois pas an faire un vrai bakup/restore avec GBAK.