Autor Téma: Transakcia nad viacerými tabuľkami - Commit, Rollback. V dávkach / naraz.  (Přečteno 221 krát)

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 2996
  • Karma: 29
    • Verze Delphi: XE7 professional
Robím výpočty a výsledky ukladám, teraz, do 18 tabuliek. Rádovo sa môže jednať celkovo o 1 - 2 tisíc záznamov. Teraz to robím v dávkach podľa druhu výpočtu. A len pár záznamov. Pre každú dokončenú dávku volám Commit.
Otázka znie: ak to urobím v jednej dávke na spôsob
Kód: [Vybrat]
  A.Transaction.Start.

  try
    Komplet výpočet
    A.Transaction.Commit;
  except
    A.Transaction.Rollback;
    raise;
  end;
je to DB totálne jedno? Alebo tam môžu vyskočiť nejaké problémy?
Dopad na výkon, systémové prostriedky ...
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1864
  • Karma: 90
    • Verze Delphi: D2007, XE3, DX10
je to DB totálne jedno? Alebo tam môžu vyskočiť nejaké problémy?
Dopad na výkon, systémové prostriedky ...
Jedno ji to pravdepodobne neni, ale zalezi na konkretnim RDBMS a konkretnich vlastnostech transakce.

Ja se s tim v praxi setkal jen jednou u IBM DB/2, kdyz nam pretekal transakcni log, protoze jsem meli v DB ulozena sifrovana data a byl pozadavek periodicky menit hesla, takze jsme to museli pri zmene hesla take presifrovavat en block. Ale tech zaznamu byly stovky tisic...

Vyzkousej, zmer a uvidis, bude to nejrychlejsi a nejpresnejsi, protoze na to IMHO stejne nedostatnes dostatecne presnou odpoved.
« Poslední změna: 10-10-2017, 14:31:43 od pf1957 »

Offline Stanislav Hruška

  • Padawan
  • ******
  • Příspěvků: 2996
  • Karma: 29
    • Verze Delphi: XE7 professional
Ja som bol hlavne zvedavý, či tam nie je nejaký zásadný problém. Ako som predpokladal, tak podľa odpovede nie je.
Rýchlosť vykonania ma netrápi. Skôr nechcem mať v DB zbytočné údaje, ak to celé nezbehne. Ale aj tak by sa nič zásadné nestalo.
Ďakujem.
Delphi XE7, FireBird
Expert na kladenie nejasne formulovaných otázok.

Offline pf1957

  • Padawan
  • ******
  • Příspěvků: 1864
  • Karma: 90
    • Verze Delphi: D2007, XE3, DX10
Ja som bol hlavne zvedavý, či tam nie je nejaký zásadný problém. Ako som predpokladal, tak podľa odpovede nie je.
Rýchlosť vykonania ma netrápi. Skôr nechcem mať v DB zbytočné údaje, ak to celé nezbehne. Ale aj tak by sa nič zásadné nestalo.
Nevim, jestli to porad plati, ale FB neuklizel automaticky po rollbacku, takze vyzadoval cas od casu rucni uklid.
https://firebirdsql.org/manual/gfix-housekeeping.html

Offline vandrovnik

  • Hrdina
  • ****
  • Příspěvků: 285
  • Karma: 17
    • Verze Delphi: 10.2
Ja som bol hlavne zvedavý, či tam nie je nejaký zásadný problém. Ako som predpokladal, tak podľa odpovede nie je.
Rýchlosť vykonania ma netrápi. Skôr nechcem mať v DB zbytočné údaje, ak to celé nezbehne. Ale aj tak by sa nič zásadné nestalo.
Nevim, jestli to porad plati, ale FB neuklizel automaticky po rollbacku, takze vyzadoval cas od casu rucni uklid.
https://firebirdsql.org/manual/gfix-housekeeping.html

Píšou:
Firebird will automatically sweep through the database and remove the remnants of rolled back transactions and this has two effects:  ...

Tzn. během sweep, který běhává obvykle i automaticky, pokud to admin nevypne, by se tyhle zbytky měly také uklidit.


Offline pepak

  • Guru
  • *****
  • Příspěvků: 1299
  • Karma: 28
    • Pepak.net
je to DB totálne jedno? Alebo tam môžu vyskočiť nejaké problémy?
Dopad na výkon, systémové prostriedky ...
Firebirdu je to totálně jedno. Pokud budeš transakce často rušit, bude se zvětšovat velikost souboru s databází, nebude to ale mít vliv na rychlost ani nic podobného. Zmenšení, pokud bys po něm toužil, dosáhneš pomocí backup+restore.

U jiných databází to může být jinak, záleží na tom, jak přesně řeší transakce.

 

S rychlou odpovědí můžete používat BB kódy a emotikony jako v běžném okně pro odpověď, ale daleko rychleji.

Jméno: E-mail:
Ověření:
Datový typ v Delphi, který má True a False: