Ergebnis der Suchanfrage

• Forum: Datenbanken

  Re: Konzept zur Datenbanktrennung.

    Delphi
    by Elvis, 6. Sep 2008
  Ich denke nur nicht, dass das hier wirklich notwendig ist. Eine Firebird DB kann durch die hunderte bis 10-Tausenden an Recordversionen, die durch offenstehende Transaktionen generiert werden, um Größenordnungen größer werden als sie wirkich ist.
  Eine klassische DW-Lösung nicht-operativer Daten ist immer möglich. Aber sein Problem wäre damit nicht gelöst. Nur die Symptome für die...
• Forum: Datenbanken

  Re: Konzept zur Datenbanktrennung.

    Delphi
    by Elvis, 6. Sep 2008
  Dadurch werden implizite Transaktionen gestartet.
  Firebirds großer Vorteil ist nämclh gleichzeitig auch seine Achillesferse: Versionierung von Datensätzen und wirklich Snapshottransaktionen.
  In den Moment, in dem du ein Select ohne eine Transaktion ausführst, wirst du implizit eine Snapshot-Transaktion der egsamten DB bekommen.
  Solange du diese nicht beendet hast, muss der DB Server für JEDE...
• Forum: Datenbanken

  Re: Konzept zur Datenbanktrennung.

    Delphi
    by Elvis, 5. Sep 2008
  Teste mal ein Backup auf eine andere Platte auf dem gleichen System wie der FB Server.
  Oder eine andere Maschine, die dann aber mindestens mit GBit LAN mit dem FB Server verbunden ist. (gbak läuft dann auf der anderen Maschine)
  
  Woher wisst ihr überhaupt, dass ein Backup/Restore(B&R) so lange dauert? :zwinker:
  Kann es sein, dass ihr das öfters macht? Normal sollte das nur notwendig sein, wenn...
• Forum: Datenbanken

  Re: Konzept zur Datenbanktrennung.

    Delphi
    by Elvis, 5. Sep 2008
  Das mag sich jetzt ziemlich blöd anhören, aber eigentlich sollte diese Maßnahme nicht notwendig sein.
  
  Wenn du die DB abfragst, sollten die Felde, die zum Filtern nötig sind, indiziert sein.
  Indizierte Suchen bedeuten, dass die Größe der Tabelle nur noch eine sehr, sehr kleine Rolle spielt.
  
  Magst du vielleicht mal die Abfragen zeigen, die euch Sorgen machen? Und vllt auch die Table DDLs...