[FB 1.5] IBRestoreService et ShutDown

[jlf]

je voudrais automatiser la restauration d'une base avec un TIBRestoreService, mais je ne sais pas si ce compo fait un Shutdown systématique de la base pendant le restore, ou s'il faut le faire avec un autre compo IB ?

merci de votre aide

[jlf]

je reviens avec mon pbm de backup / shutdown / restore

j'ai ces 3 fonctions :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
procedure TForm1.Sauve(Fdb, Fbk : string);
begin
  WITH IBBackupService1 do
  begin
    Active := True;
    try
      verbose := True;
      DatabaseName := Fdb;
      BackupFile.Text := Fbk;
      ServiceStart;
      While NOT Eof do
        Memo1.LINES.ADD(GetNextLine);
    finally
      Active := False;
    end;
  end;
end;
 
procedure TForm1.ShutDown(Fdb : string);
begin
  WITH IBConfigService1 do
  begin
    try
      DatabaseName := Fdb;
      Active := True;
      ShutdownDatabase(Forced, 0);
      while IsServiceRunning do Sleep(10);
    finally
      Active := False;
    end;
  end;
end;
 
procedure TForm1.Restaure(Fdb, Fbk : string);
begin
  IBRestoreService1.Active := True;
  try
    IBRestoreService1.DatabaseName.Text := Fdb;
    IBRestoreService1.BackupFile.Text := Fbk;
    IBRestoreService1.ServiceStart;
    while NOT IBRestoreService1.EOF do
      Memo1.LINES.ADD(IBRestoreService1.GetNextLine);
  finally
    IBRestoreService1.Active := False;
  end;
end;

les params du IbRestore sont à [Replace, CreateNew]


si personne n'est connecté à la base la séquence :
Sauve;
ShutDown;
Restaure;
fonctionne sans pbm, et le restaure remet même la base en ligne sans avoir à faire un BringDataBaseOnLine

en revanche que lorsqu'une autre connexion est active (si par ex j'ouvre la base dans IBExpert avant de lancer la séquence) le restaure échoue avec un message du genre "base probablement occupée"

pourtant le ShutDown a fonctionné, lorsque je reviens dans IBExpert il me signale bien que la connexion est fermée

j'ai essayé de temporiser après le Shutdown en posant des points d'arret, des ProcessMessage, des sleep, rien n'y fait la restauration échoue toujours

qu'est ce qui cloche ?

[makowski]

ShutDown;
Sauve;
Restaure;
Online;

[jlf]

Envoyé par makowski

ShutDown;
Sauve;
Restaure;
Online;

ça ne marche pas non plus ...

[makowski]

et bien change de composants

[VLDG]

dans le IBRestoreService1, il faut je pense simplement ajouter l'option Replace.

Code :

1
2
3
4
5
6
7
8
9
10
11
  IBRestoreService1.Active := True;
  try
    IBRestoreService1.Options := IBRestoreService1.Options + [REPLACE];
    IBRestoreService1.DatabaseName.Text := Fdb;
    IBRestoreService1.BackupFile.Text := Fbk;
    IBRestoreService1.ServiceStart;
    while NOT IBRestoreService1.EOF do
      Memo1.LINES.ADD(IBRestoreService1.GetNextLine);
  finally
    IBRestoreService1.Active := False;
  end;

[Zywack]

J'ai un problème similaire, même en utilisant seulement gfix et gbak (Firebird 1.5). Si il y a une connection présente sur la base de donnée, le Shutdown ne cancelle pas cette connection, et il est impossible de faire un Restore sur la base de donnée. Voici les commandes que j'envoie:

1) gfix.exe -user SYSDBA -password masterkey mydatabase.fdb -shut -force 0

2) gbak.exe -user SYSDBA -password masterkey mydatabase.fdb mydatabase.fbk

3) gbak.exe -c -r -user SYSDBA -password masterkey mydatabase.fbk mydatabase.fdb

4) gfix.exe -user SYSDBA -password masterkey mydatabase.fdb -Online


Si je n'ai pas de connections externe à la base de donnée, tous fonctionne bien, le backup/restore se complète normallement. Le shutdown fonctionne lui aussi, puisqu'avant le Online, je ne peux pas créer de nouvelles connections à la base de donnée.
En revanche, si j'ai une connection sur la base de donnée active avant l'étape #1 (Avec IBView par exemple, mais le résultat est le même peu importe la connection), le restore me retourne "database might be in use". Toute les opérations que je fais avec la connection 'active' de IBView me retourne comme erreur: "Database Shutdown" (Qui est normal), mais le Restore ne fonctionne pas tant que je ne ferme pas manuellement la connection dans IBView... Est-ce qu'il me manque quelque chose à mon Shutdown pour qu'il coupe complètement toute les connections active...?

[makowski]

quelle version exacte de Firebird ?
parce qu'avec la 1.5.4 SS windows tout fonctionne correctement

Code :

1
2
C:\>isql 127.0.0.1:E:\mesbases\MABASE.FDB -user SYSDBA -password masterkey
DATABASE:  127.0.0.1:E:\mesbases\MABASE.FDB, User: SYSDBA

puis sur une autre console :

Code :

C:\>gfix -user SYSDBA -password masterkey 127.0.0.1:E:\mesbases\MABASE.FDB -shut -force 0

retour sur la première console :

Code :

1
2
3
4
5
SQL> SHOW DATABASE;
Statement failed, SQLCODE = -902
 
DATABASE E:\mesbases\MABASE.FDB shutdown
SQL>

[Zywack]

J'ai la version 1.5.2.4731. J'ai vérifié avec Firebird 2.0 et j'ai le même problème même avec le Full shutdown.

Une note importante est que j'ai le même résultat que toi: Après le Shutdown, j'ai moi aussi le message "MABASE.FDB shutdown" lorsque j'essaye de faire une opération avec IBView.

Le problème est que selon gbak, la connection est encore active, donc il est impossible de faire le Restore ("database might be in use"). Selon IBView (ou ISQL, aucune importance), la base de donnée est bel et bien en shutdown puisqu'il est impossible d'utiliser les connections à la base de donnée ou d'en créer une autre, mais les connections qui étaient présente ne sont pas déconnecté a 100% selon gbak. À ce point ci, si je ferme IBView ou ferme la connection (Qui est sous shutdown et donc inutilisable), je peux faire le Restore.

Bref, le shutdown semble fonctionner pour bloquer les connections actuelle et empêcher de créer de nouvelles connections, mais ne semble pas "déconnecter" les connections actuelle complètement.

Merci!

[makowski]

Envoyé par Zywack

Bref, le shutdown semble fonctionner pour bloquer les connections actuelle et empêcher de créer de nouvelles connections, mais ne semble pas "déconnecter" les connections actuelle complètement.

C'est une très très mauvaise idée d'écraser une base
il est largement préférable de restaurer ailleurs et ensuite, quand on est certain que tout va bien, mettre la nouvelle base en place, ce qui, quand on utilise les alias est simplissime

[Zywack]

Voici ma situation: J'ai un programme à multiple utilisateurs sur un réseau, utilisé par des personnes qui on des connaissances informatique pratiquement nulle . Une des tâches automatisé de notre fonction "Fin de Journée" est de créer un backup de la base de donnée.

Selon plusieurs sources que j'ai lu, il est important de faire un Restore pour empêcher les corruptions de base de données Firebird et aider à garder l'intégrité de la base de donnée. Puisque nous avons plusieurs site, il est impossible de faire ce processus manuellement pour simple maintenance journalière. Donc, ce que nous faisons est l'ordre suivant:

1) Faire une copie de BaseDonnee.fdb à BaseDonneeAvantRestore.fdb au cas ou le restore à une erreur. Donc, il y a toujours une copie de la base de donnée sécure.
2) Faire un Shutdown pour fermer toute les connections (Aucune n'est utilisé puisque c'est en fin de journée et les utilisateurs ont tendance à rester leur logiciel ouvert avant de partir).
3) Faire un backup avec la date pour l'identifier uniquement.
4) Faire le restore sur BaseDonnee.fdb. C'est ici que le problème est du au connections qui sont consideré active.

Le processus ci-haut est automatisé, le problème est que le Shutdown ne ferme pas les connections active à la base de donnée.

Même si je fais un restore séparement, je ne peux pas remplacer automatiquement la base de donnée durant le "copy", à cause des connections 'active'. Faire un restore manuellement en cas d'urgence n'est pas vraiment une issue: Nous fermons manuellement les connections et faisons le restore par la suite. Le problème est le restaure 'automatique' pour empêcher la corruption de la base de donnée.

Si il y a une autre alternative pour empêcher la corruption occasionelle autre que faire un Restore commun, ce serait évidamment idéal. Ou bien que Firebird 2 n'a plus besoin d'un restore occasionel pour éviter les erreurs. Sinon, il me faut une manière de fermer toute les connections à la base de donnée pour effectuer le restore automatique.

Merci, et désolé pour la longue explication en dehors du sujet!

[makowski]

Envoyé par Zywack

Si il y a une autre alternative pour empêcher la corruption occasionelle autre que faire un Restore commun, ce serait évidamment idéal.

Un backup/restore n'a jamais empéché des corruptions , c'est quoi cette légende ????

Une bonne gestion des tansaction, un backup quotidien (avec test de restauration régulier) et un sweep régulier (éventuellement quotidien) suffisent largement à la bonne santé d'une base

[Zywack]

Et bien, ça simplifie certainement ma situation. Merci beaucoup!

Je vais envoyer un couriel au créateurs des articles que j'ai lu qui explique la "nécéssité" des restores pour empêcher la corruption et aviser mes collègues. Mieux vaut stopper la mauvaise information le plus tôt possible!

Merci encore une fois makowski!

[isc_base]

Bonjour à tous,

Je travaille actuellement sur un projet utilisant fortement firebird 1.5 et je viens de tomber sur exactement le même problème que celui décrit par jlf à la différence que je code en C++ Linux/Windows et que j'appelle donc directement les fonctions de fbclient.dll/fbclient.so :

- shutdown d'une base A.gdb (en SYSDBA) OK
- restauration d'un backup de A.gbk sur A.gdb
- erreur de restauration (database in use)

Si l'on regarde ce qu'il se passe au niveau des connexions TCP on s'aperçoit que lors du shutdown les clients sont bien déconnectés au niveau firebird mais que les connexions TCP restent actives.

La réponse comme quoi il ne faut pas restaurer un backup sur une base existante ne me satisfait pas. La fonctionnalité est présente dans firebird (gbak -r) donc on doit pouvoir l'utiliser même au prix de la perte de quelques données non commités (prix que je suis prêt à payer pour mon projet actuel). Sinon comment fait-on pour remplacer une base sans arrêter firebird ? Une copie au niveau du file system ? Déjà essayé : on se retrouve très vite avec des bases vérolées.

Merci d'avance à tous les gurus de firebird qui jetterons un œil à mon problème.

[makowski]

avec quel utilisateur sont connectés les clients ?
si c'est SYSDBA ou le propriétaire de la base, avec fb1.5 ils peuvent toujours se connecter
par contre si c'est un autre utilisateur non

et dans fb2, il existe de nouveau mode de shutdown, nottament un qui ne permet qu'une seule connexion

et gbak -r est vraiment déconseillé à tel point que maintenant c'est :
gbak -REP ou -R[ECREATE_DATABASE] OVERWRITE.

si par malheur ta sauvegarde n'est pas bonne, avec un replace et bien tout est perdu

[isc_base]

oui en effet j'avais oublié de préciser qu'il n'y a que le process qui s'occupe de remplacer la base qui se connecte en tant que SYSDBA et que toutes mes bases sont créées par SYSDBA. Les applications travaillant sur ces bases se connectent avec un login dépendant de leur domaine de compétence mais ne créent pas les bases.

Je comprends bien que l'opération et périlleuse mais dans mon contexte le risque est assumé et l'opération peut être renouvelée au moindre problème. Et donc ce que je cherche à faire est bien un 'R[ECREATE_DATABASE] OVERWRITE'. Triste sort pour une donnée que d'être supprimée

Donc je reviens à mon problème. Ma config de debug est la suivante :
Une workstation sous XP SP2 avec Firebird v.1.5.4.4910 et Quickdesk 2.5.0.1. Un serveur sous Ubuntu avec Firebird LI-V1.5.3.4870.

- Sur le serveur Ubuntu j'ai une base BDD.gdb et sa version compactée BDD.gbk. Créée comme suit:

Code :

gbak -b -user SYSDBA -password masterkey BDD.gdb BDD.gbk

1 - Je démarre Quickdesk et je me connecte comme USER à Ubuntu:BDD.gdb.
2 - Sur le serveur Ubuntu j'execute la commande :

Code :

gfix -shut -force 0 -user SYSDBA -password masterkey BDD.gdb

3 - Quickdesk annonce : 'Connection lost. Database will be closed!'
4 - Sur le serveur Ubuntu la commande suivante échoue:

Code :

1
2
3
gbak -r -k -user SYSDBA -password masterkey BDD.gbk BDD.gdb
gbak: ERROR: could NOT DROP DATABASE BDD.gdb (DATABASE might be IN USE)
gbak: Exiting before completion due TO errors

5 - Je ferme Quickdesk et je relance la commande précédente sur le serveur Ubuntu et ça passe.
6 - Remise online de la base:

Code :

gfix -online -user SYSDBA -password masterkey BDD.gdb

GOTO 1

Mon application utilise la service API pour effectuer l'équivalent des commandes gbak et gfix décrites dans la procédure pour obtenir un résultat identique. Si l'on met de côté le fait qu'elle est dangereuse, ma procédure est-elle correcte ?