ODS 11.0 auf 11.1 (Firebird 2.03 auf 2.1)

funcry · Verfasst: So 27.04.08 13:08

Auch wenn es nicht direkt Delphi betrifft, aber vielleicht hat jemand schon das Problem gelöst.

Ich würde gerne die ODS Version 11.1 nutzen welche Firebird 2.1 mitbringt, und eine bestehende Firebird 2.03 Datenbank mit ODS 11.0 upgraden.

Laut Doku (so wie ich es verstanden habe) sollte nbackup das bewerkstelligen, jedoch mit gstat wird mir nach einem Backup und Restore immer noch 11.0 angezeigt.

Folgenden Befehl gebe ich ein:

Sicherung:

markieren

Quelltext

1:	nbackup -U SYSDBA -P masterkey -B 0 test "c:\blub\Backup_DB_jetzt.nbk"

Wiederherstellung:

markieren

Quelltext

1:	nbackup -U SYSDBA -P masterkey -R test "c:\blub\Backup_DB_jetzt.nbk"

Hinweis:
"test" ist ein Alias der auf die Datenbankdatei zeigt. Das Tool läuft durch, aber die ODS ändert sich leider nicht.

funcry · Verfasst: So 27.04.08 13:30

gelöst:

"gbak" sichern und restore bringt die ODS auf 11.1. Die Datenbank schrumpfte dadurch um 20%.

Anbei:
Performancegewinn in meiner Anwendung von 2.03 auf 2.1 rund 7%.

Amiga-Fan · Beiträge: 534

der Performance-Gewinn hat wohl eher mit dem Backup-Restore-Zyklus zu tun, als mit der neueren Firebird-Version...

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

mkinzler · Verfasst: Mo 28.04.08 10:36

Warum dass? Bei ordentlicher Datenmodellierung sollte die anzahl der Daten keinen Einfluss auf die Performance haben.

_________________
Markus Kinzler.

Amiga-Fan · Beiträge: 534

das war eher eine Vermutung, aber wenn du das sagst ziehe ich das zurück, du kennst dich damit besser aus als ich

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

funcry · Verfasst: Mo 28.04.08 12:47

Daran habe ich auch schon gedacht, es wäre durchaus möglich..., da speziell diese Thematik eher durch Probieren als durch Wissen von mir angegangen wurde.

Durch ausgiebige Performance Messungen jeder einzelnen SQL-Abfrage habe ich versucht die benötigten Indices richtig zu setzen, der Performancegewinn war damals enorm. Allerdings entsprechen die Testdaten mit denen ich die DB für die Messungen gefüllt habe nicht den tatsächlichen Daten. Das ergibt sich auch aus der Thematik dass ich für Perfomance-Tests eine größere Datenbank benötigt habe (> 1GB) um brauchbare Messwerte zu erhalten.

Zudem beherrsche ich das richtige Interpretieren der Firebird-Statistik noch nicht. Kann mir jemand einen Link zu einem Tutorial etc. geben um die Firebird-Statistik richtig zu verstehen ?

Weiter ist mir unklar was neben der Datensicherung "gut" für die Datenbank ist. Momentan sichere ich die DB nachts mittels nbackup. Mir ist zzt. nicht klar was ein "Sweep" ist und ob ich regelmäßig bestimmte Operationen (Sweep, gbak, garbage collection) mit der Datenbank durchführen sollte, und was diese bringen.

Anbei ein Auszug aus der Statistik meines Testsystemes:

markieren

Quelltext

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:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:

Database header page information: 
  Flags      0 
  Checksum    12345 
  Generation    301 
  Page size    8192 
  ODS version    11.1 
  Oldest transaction  290 
  Oldest active    291 
  Oldest snapshot    291 
  Next transaction  293 
  Bumped transaction  1 
  Sequence number    0 
  Next attachment ID  27 
  Implementation ID  16 
  Shadow count    0 
  Page buffers    0 
  Next header page  0 
  Database dialect  3 
  Creation date    Apr 27, 2008 13:21:14 
  Attributes    force write 
 
    Variable header data: 
  Sweep interval:    20000 
  *END* 



[...]


VM (130) 
    Primary pointer page: 153, Index root page: 154 
    Data pages: 27, data page slots: 27, average fill: 84% 
    Fill distribution: 
   0 - 19% = 0 
  20 - 39% = 0 
  40 - 59% = 0 
  60 - 79% = 0 
  80 - 99% = 27 
 
    Index FK_A3_A1 (1) 
  Depth: 1, leaf buckets: 1, nodes: 1435 
  Average data length: 0.07, total dup: 1422, max dup: 514 
  Fill distribution: 
       0 - 19% = 0 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 1 
      80 - 99% = 0 
 
    Index FK_A3_A10 (3) 
  Depth: 1, leaf buckets: 1, nodes: 1435 
  Average data length: 0.03, total dup: 1430, max dup: 512 
  Fill distribution: 
       0 - 19% = 0 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 1 
      80 - 99% = 0 
 
    Index FK_A3_A2 (2) 
  Depth: 1, leaf buckets: 1, nodes: 1435 
  Average data length: 0.11, total dup: 1415, max dup: 427 
  Fill distribution: 
       0 - 19% = 0 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 1 
      80 - 99% = 0 
 
    Index PK_VM (0) 
  Depth: 2, leaf buckets: 3, nodes: 1435 
  Average data length: 7.09, total dup: 0, max dup: 0 
  Fill distribution: 
       0 - 19% = 1 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 0 
      80 - 99% = 2

Nachtrag: Die Statistik vom eingesetzten System aus dem laufenden Betrieb heraus:

markieren

Quelltext

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:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:

Database header page information: 
  Flags      0 
  Checksum    12345 
  Generation    381 
  Page size    8192 
  ODS version    11.1 
  Oldest transaction  281 
  Oldest active    282 
  Oldest snapshot    282 
  Next transaction  373 
  Bumped transaction  1 
  Sequence number    0 
  Next attachment ID  15 
  Implementation ID  16 
  Shadow count    0 
  Page buffers    0 
  Next header page  0 
  Database dialect  3 
  Creation date    Apr 28, 2008 9:57:49 
  Attributes    force write 
 
    Variable header data: 
  Sweep interval:    20000 
  *END* 

[...]

VM (130) 
    Primary pointer page: 153, Index root page: 154 
    Data pages: 28, data page slots: 28, average fill: 82% 
    Fill distribution: 
   0 - 19% = 1 
  20 - 39% = 0 
  40 - 59% = 0 
  60 - 79% = 0 
  80 - 99% = 27 
 
    Index FK_A3_A1 (1) 
  Depth: 1, leaf buckets: 1, nodes: 1444 
  Average data length: 0.07, total dup: 1431, max dup: 514 
  Fill distribution: 
       0 - 19% = 0 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 1 
      80 - 99% = 0 
 
    Index FK_A3_A10 (3) 
  Depth: 1, leaf buckets: 1, nodes: 1452 
  Average data length: 0.03, total dup: 1447, max dup: 513 
  Fill distribution: 
       0 - 19% = 0 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 1 
      80 - 99% = 0 
 
    Index FK_A3_A2 (2) 
  Depth: 1, leaf buckets: 1, nodes: 1444 
  Average data length: 0.11, total dup: 1424, max dup: 426 
  Fill distribution: 
       0 - 19% = 0 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 1 
      80 - 99% = 0 
 
    Index PK_VM (0) 
  Depth: 2, leaf buckets: 3, nodes: 1444 
  Average data length: 7.09, total dup: 0, max dup: 0 
  Fill distribution: 
       0 - 19% = 1 
      20 - 39% = 0 
      40 - 59% = 0 
      60 - 79% = 0 
      80 - 99% = 2

Amiga-Fan · Beiträge: 534

also bei mir ist er vorhin durch den Backup-Restore-Zyklus eindeutig schneller geworden.

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

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme