🚀 go-pugleaf

> To znaczy, że zdarza się, że select z tych tabel daje dobre dane, a widać 
> kolosalne spowolnienie podczas backupowania / restorowania takiej tabeli. 
> Nieco analogicznie do znaku #0 w bloku pamięci rzutowanego na PChar - 
> odczytujesz do pierwszego znaku #0 mimo że blok jest dużo większy i dalej 
> ma jakieś znaki.
>

A widzisz ... nieprezycyjny opis dałeś (albo coś przeoczyłem) ... rozumiem, 
że puchną pola BLOB a to jest zupełnie inna bajka.
Obstawiam błąd programu, która właśnie tyle zapisuje do bloba ale 
rewolucyjnej czujności nigdy dość.


>>> W czasie robienia operacji na tabeli typu SELECT, tabela przez jaki� 
>>> czas
>>> jeszcze jest mo�liwa do odczytania, cho� og�lnie wydajno�� ca�ej bazy
>>> spada, a tej tabeli - drastycznie spada.
>>

No bo jak ma gigantyczne bloby to i spadać musi.

> Tabel jest > 100, tabele mają rekordów od 0 (sic!) do dziesiątek tysięcy.

Czyli tabele są prawie puste.

> Pisałem, że psują się te tabele w zasadzie losowo, nie byłem w stanie do 
> teraz ustalić jakiegokolwiek klucza, typu "psują się tabele x, y i czasem 
> z"

Jeśli we wszystkich tabelach używasz do zapisu Blobów tej samej procedury w 
programie to ja najpierw zająłbym się tą procedurą.

Nie wiem jak piszesz do tegoż bloba, pokaż ten fragment programu.
Może nie zerujesz np. stringa, którego zawsze zapisujesz, może jakieś 
nieszczęśliwe rzutowanie.
Sprawdzaj ile faktycznie zapisujesz w programie i daj komunikat jak coś nie 
pasuje.

> Czasem są, czasem nie są. Dziwne pytanie.
> Jak Ci woda piwnicę zaleje to czasem zniszczy się coś potrzebnego, a 
> czasem rupieć, prawda?

Jak zaleje mi moją piwnicę to nie ważne, ale sąsiada z mojego kranu to 
zawsze jest mu potrzebne wszystko co mu się właśnie zalało.

>>> Problem jest stosunkowo rzadki, mo�e jeden na 1000 przypadk�w, mo�e 
>>> jeden
>>> na 500, ale jest to sprawa na tyle powa�na, �e zaczyna niepokoi�.

Nie wiem jak wersja FB2.5 ale na poprzednich wersjach nigdy mi taki problem 
nie wystąpił, mimo, że klienci różne "fajne" rzeczy z komputerami robią.

>>> Czy ja co� robi� w programie bardzo niedobrego, typu "trzymasz 
>>> connection
>>> do bazy otwarty ca�y czas? nie id� t� drog�!"

Nic z tych rzeczy, nadal obstawiam, że właśnie to jest zapisywane co jest w 
bazie i niejako FB nie ma nic do tego, on wykonuje posłusznie żądane 
operacje.

>> Dodaj trigger before insert do tych tabel i wygeneruj w nim wyj�tek gdy
>> dochodzio do zapiu owych "zer".


>
> nie bardzo wyobrażam sobie, jak bym miał to stwierdzić
>


piszę z głowy czyli z niczego

create exception E_RANYBOSKIE 'Wielki blob';

CREATE TRIGGER TABELA_BEFORE_INSERT FOR TABELA
  ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (CHAR_LENGTH(NEW.TABELA_BLOB) > 10000) THEN
      EXCEPTION E_RANYBOSKIE
END

na wszelki wypadek też dla UPDATE

dodaj do tabeli pole na długość bloba, wtedy w TRIGGERZE bedziesz mógł 
sprawdzzić czy

CHAR_LENGTH(NEW.TABELA_BLOB) = NEW.TABELA_BLOBLEN

-mh