Grösse der Firebird-Datenbankdatei auslesen

Amiga-Fan · Beiträge: 534

das ist wahrscheinlich ganz einfach und ich habe es nur übersehen :oops:

Angenommen ich habe eine entfernte Datenbank-Verbindung übers Internet, und ich möchte die Größe der zugrundeliegenden Datenbank-Datei anzeigen lassen, wie kann ich das auslesen? Ich weiß nur wie es mit lokalen Dateien geht, in der Hilfe hier habe ich auch nur was zu lokalen Dateien gefunden. Ich verwende die IBX-Komponenten. Bei den IBX-Admin-Komponenten bin ich nun auch nicht fündig geworden...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

Lemmy · Verfasst: Di 31.05.05 06:54

Guten Morgen,

ich stelle einfach mal so in den Raum, dass es mit IBX nicht geht, weil das keinen interessiert! Zumindest niemanden, der auf den Inhalt der Datenbank zugreifen will. Ich gehe auch davon aus, dass es zumindest mit BS-Funktionen keine Möglichkeit gibt die Größe zu ermitteln, denn das wäre wieder ein schönes Sicherheitsloch, wenn jedermann direkten Zugriff auf die Datenbankdatei hat.

Darf man fragen zu was Du die Größe brauchst?

Lemmy

Amiga-Fan · Beiträge: 534

na klar. Ich habe in meinem Programm eine lokale Datenbank und eine (optional), die entfernt auf einem anderen Rechner liegt. Ich habe eine Kopieren-Funktion eingebaut (also synchronisieren). Vor dem Kopieren wäre es wichtig zu wissen, wie groß die Quell-DB ist, ->wie lange die Übertragung dauert<- entscheidender Punkt, ob genug Platz auf dem Medium der Ziel-DB ist... sowas halt. Das sowas keinen interessiert halte ich für unwahrscheinlich, außerdem besteht kein Grund, gleich misstrauisch zu werden. In Oracle kann man es glaube ich auch einsehen (vermutlich auch auslesen), weiß es aber jetzt nicht im Kopf.

Edit: klar kann man das in Oracle einsehen, in der Enterprise Manager Console unter Speicher -> Tablespaces. Also wird es wohl auch irgendwie mit Firebird/IBX gehen (vielleicht über die Systemtabellen? Muß zu Hause nochmal prüfen). Scheinbar interessiert sich doch jemand dafür. :wink:

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

CenBells · Beiträge: 1547 Win 7 Delphi XE5 Pro

Hi,

in Oracle hast du aber nicht eine Datei. Dort kannst Du auch nur den sogenannten Tablespace auslesen, der einer DB zugewiesen wurde bzw von Ihr alloziert wurde.

Aber was anderes. Du solltest Dir für dein vorhaben entweder eine ordentliche Synchronisierungsroutine einbauen (direkt zu der entfernten DB verbinden und nur die Datensätze übermitteln, die auf der Client Seite neu sind) oder wenigstens ein Backup rüberschieben. Die GDB Datei sollte nie direkt kopiert werden.

Mit freundlichen Grüßen
Ken

_________________
Eine Klasse beschreibt die Struktur und das Verhalten einer Menge gleichartiger Objekte.

Amiga-Fan · Beiträge: 534

Gut aber auch bei Firebird interessiert ja nur der gesamte benutzte Speicherplatz, und dort wird eben direkt zu einer Datei verbunden.

Zitat:

(direkt zu der entfernten DB verbinden ...

tue ich bereits.

Zitat:

und nur die Datensätze übermitteln, die auf der Client Seite neu sind)

das muss ich noch machen. Aber vielleicht lasse ich das auch weg, in der DB können auch Binärdaten gespeichert werden (JPG-Bilder)...

Zitat:

Die GDB Datei sollte nie direkt kopiert werden.

tue ich ja auch nicht, ich mache SELECT auf der Quell-DB und dann INSERT auf der Ziel-DB. Und dafür möchte ich irgendwie abschätzen, wie lange vorraussichtlich der Vorgang dauert. Dazu wäre es schon interessant zu wissen, wie groß die Quell-Datei ist.

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

CenBells · Beiträge: 1547 Win 7 Delphi XE5 Pro

hi,

habe gerade im Firebird book nachgeschaut.

Ich habe eine Möglichkeit gefunden, wie man die größe der Datei ermitteln kann. Diese bezieht sich allerdings nur auf isql.
Dort ein einfaches SHOW DATABASE; reicht.
Die Ausgabe sieht dann etwa wie folgt aus

Zitat:

Database: deine datei
Owner: SYSDBA
PAGE_SIZE 4096
Number of DB pages allocated = 6163
Sweep interval = 20000
Forced Writes are OFF
Transaction - oldest = 911810
Transaction - oldest active = 913528
Transaction - oldest snapshot = 913527
Transaction - Next = 913733
Default Character set: ISO8859_1

(Anzahl der Seiten * Seitengröße) gibt die Größe der DB-Datei an. Die kann im Verlauf eines Backup-Restore-Zyklus noch deutlich kleiner werden.

Gruß
Ken

_________________
Eine Klasse beschreibt die Struktur und das Verhalten einer Menge gleichartiger Objekte.

Lemmy · Verfasst: Di 31.05.05 11:13

Amiga-Fan hat folgendes geschrieben:

na klar. Ich habe in meinem Programm eine lokale Datenbank und eine (optional), die entfernt auf einem anderen Rechner liegt. Ich habe eine Kopieren-Funktion eingebaut (also synchronisieren). Vor dem Kopieren wäre es wichtig zu wissen, wie groß die Quell-DB ist, ->wie lange die Übertragung dauert<- entscheidender Punkt, ob genug Platz auf dem Medium der Ziel-DB ist... sowas halt.

Gut... mach mal... das heißt aber nicht synchronisieren sondern einfach kopieren. Ich hoffe Du weißt, dass

1. Du mit einfachem kopieren einer Firebird-Datenbankdatei diese komplett schrotten kannst.
2. Wenn Du einen direkten Zugriff auf die Serverdatenbank hast, den auch andere haben könnten!

Schau Dir mal bestehende Lösungen an (Replikationssoftware): www.2p.cz/en/interbase_replicator/ kosten wenig Geld und funktionieren auch ohne Tricks...

Lemmy

Amiga-Fan · Beiträge: 534

Zitat:

2. Wenn Du einen direkten Zugriff auf die Serverdatenbank hast, den auch andere haben könnten!

das soll eine öffentliche Datenbank sein, ist auch nur mein privates Programm, das ich vielleicht weitergebe.

Zitat:

1. Du mit einfachem kopieren einer Firebird-Datenbankdatei diese komplett schrotten kannst.

Was verstehst du jetzt unter kopieren? Ich mache SELECT und INSERTs, also kein Kopieren der Datei direkt. Die Daten auf der Ziel-DB werden vorher gelöscht. Das geht ja auch schon. Dazu benutze ich Transaktionen. Die quell-DB sollte vor dem snchro. gelockt werden, damit keine Veränderungen gemacht werden können, bevor das snchro. abgeschlossen ist. Bei einem Neutstart des Programms wird der Lock dann immer weggenommen, falls das Programm abgestürzt ist.

Zitat:

Schau Dir mal bestehende Lösungen an (Replikationssoftware): www.2p.cz/en/interbase_replicator/ kosten wenig Geld und funktionieren auch ohne Tricks...

bei einem Shareware-Projekt will ich möglichst wenig geld ausgeben, vielleicht...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

Lemmy · Verfasst: Di 31.05.05 12:44

Amiga-Fan hat folgendes geschrieben:

Zitat:

1. Du mit einfachem kopieren einer Firebird-Datenbankdatei diese komplett schrotten kannst.

Was verstehst du jetzt unter kopieren?

copy datenbank.fdb \\server\datenbank.fdb

Einfaches Dateikopieren eben.... So wie Du das machst ist es schon OK! Allerdings solltest Du darauf achten, dass die Größe des Datenbankfiles mit dem Löschen der Datensätze nicht kleiner wird! Das passiert erst bei einem Backup-Restore. Meines Wissens nach wird allerdings beim Insert dieser "vorgehaltene" Platz erst verbraucht. Vielleicht kannst Du das in einem kurzen Test mal nachweisen oder widerlegen.

Kleiner Tipp am Rande: Bei vielen Inserts lohnt es sich die Indizes einer Tabelle zu deaktivieren! Spart jede Menge Zeit!!!

Amiga-Fan hat folgendes geschrieben:

Zitat:

Schau Dir mal bestehende Lösungen an (Replikationssoftware): www.2p.cz/en/interbase_replicator/ kosten wenig Geld und funktionieren auch ohne Tricks...

bei einem Shareware-Projekt will ich möglichst wenig geld ausgeben, vielleicht...

verständlich....

hansa · Beiträge: 3079 Erhaltene Danke: 9

Lemmy hat folgendes geschrieben:

...Meines Wissens nach wird allerdings beim Insert dieser "vorgehaltene" Platz erst verbraucht. Vielleicht kannst Du das in einem kurzen Test mal nachweisen oder widerlegen....

Das braucht er nicht zu widerlegen, das ist so ! Also DB-Größe : 1 MB in 1000 Datensätzen. Man lösche 999. Die DB bleibt gleich groß. Nach einem Backup/Restore ist sie jedoch nur noch den 1 Datensatz groß + die Datenbankdefinition. Ohne Backup/Restore wird sie erst größer, sofern 1000 Datensätze neu angelegt werden (dann also 1001 insgesamt vorhanden sind).

_________________
Gruß
Hansa

Lemmy · Verfasst: Di 31.05.05 14:16

hansa hat folgendes geschrieben:

Das braucht er nicht zu widerlegen, das ist so !

Danke für die Bestätigung Hansa!!

Lemmy

Amiga-Fan · Beiträge: 534

endlich habe ich es ausprobiert. CenBells Lösung ist richtig, genau diese Größe zeigt er mir auch im Explorer an. Die Frage ist jetzt nur, wie ich das programmgesteuert auslesen kann. Es muss doch möglich sein, diese Ausgabe in eine Log-Datei umzulenken? Bei z. B. gbak.exe geht das ja auch, mit dem Parameter -Y. Dann hätte ich die Lösung - abgesehen davon, das ich isql.exe mit 2 Befehlen aufrufen muss (einmal connect und dann show database), und das wohl mit shellexecute nicht geht...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

CenBells · Beiträge: 1547 Win 7 Delphi XE5 Pro

Hi,

wenn ich nicht ganz auf dem falschen weg bin, kann man isql mit einer Kommandodatei aufrufen.
Also schreibst du deine Kommandodatei so, daß die ausgabe von Show Database in eine externe Datei gepiped wird (wenn möglich) oder liest halt die ausgabe auf der Kommandozeile aus.

Gruß
Ken

_________________
Eine Klasse beschreibt die Struktur und das Verhalten einer Menge gleichartiger Objekte.

Amiga-Fan · Beiträge: 534

hm wird denn isql.exe auch im Firebird-Client mitgeliefert? Ach ich schaue mal zuhause nach...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

CenBells · Beiträge: 1547 Win 7 Delphi XE5 Pro

In meiner Firebird 1.5.2 Installation gibt es im bin-Verzeichnis auch das Tool isql.

Gruß
ken

_________________
Eine Klasse beschreibt die Struktur und das Verhalten einer Menge gleichartiger Objekte.

Amiga-Fan · Beiträge: 534

nach etwas probieren habe ich es jetzt, das ist der dos-befehl:

isql 'x.fdb' -u 'sysdba' -p 'masterkey' -i batch.sql >log.txt

jetzt muss ich nur noch das log-file auswerten.

Danke für die Hilfe...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

Amiga-Fan · Beiträge: 534

ich habe doch noch eine Frage:

das Dos-Ausgabefenster verschwindet so schnell wie es gekommen ist, kann man das nicht anhalten?

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

Amiga-Fan · Beiträge: 534

ich habe doch noch ein Problem damit:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:

      
try
  strtemp:=' '+quotedstr(activeDBName)+' '+
           ' -u '+quotedstr(activeDBBenutzer)+' '+
           ' -p '+quotedstr(activeDBPasswort)+' '+
           ' -i '+Localizing.Batch_file+' '+
           ' > ' +Localizing.ExpLogFile;

  inputquery('','',strtemp);                                            // debug-code

  ErrMessage:=GlobalFunctions.ShellExecuteErrMessage(
                              ShellExecute(self.handle,
                              Nil,
                              PChar(tmpFilePath),                       // Pfad zur ISQL.exe
                              Pchar(strtemp),
                              Pchar(TempPath),                          // Anwendungsdatenverzeichnis, dort ist das Batchfile
                              SW_NORMAL));
except
end;

weiß einer warum das nicht geht? Das Ausgabefenster verschwindet zu schnell... Wenn ich den Befehl aus der InputQuery rauskopiere und so in einer DOS-Box ausführe ("isql.exe" vorangestellt natürlich), gehts...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

Amiga-Fan · Beiträge: 534

wenn ich das hier

Zitat:

' > ' +Localizing.ExpLogFile

weglasse (also die Ausgabeumlenkung) geht es, komisch... ' oder " drumrum reicht auch nicht...

er zeigt einen I/O Fehler an, der Text verschwindet aber zu schnell. Die Datei existiert jedenfalls noch nicht (und Schreibrechte existieren natürlich).

EDIT: jetzt gehts. Statt > benutze ich -o. Hätte ich eigentlich schneller drauf kommen können...

_________________
- Leg dich nie mit einem Berufsprogrammierer an
- Wahre Profis akzeptieren keine einfachen Lösungen

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme