Firebird - "puchnąca" baza danych

[Stregor]

Cześć.

Spotkał się ktoś z Was z takim zjawiskiem?
FB 2.5, baza > 100 tabel. Działa sobie normalnie, do pewnego czasu, a
nagle zaczyna "dziczeć" - wielkość pliku .fdb rośnie bardzo szybko, tak
samo wielkość .fbk. Zwykle wygląda to tak, że jedna (lub kilka) z tabel
jest "pompowana" zerami lub losowymi znakami, ale tylko w pliku. 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.

Problem potęgowany jest faktem, że taka baza może być użytkowana jeszcze
czasem przez długi czas, aż dostęp do niej stanie się całkowicie
niemożliwy. I wtedy okazuje się, że na przykład kopie zapasowe też są
błędne - już od roku...

Sztuczki typu gbak/grestore z wszelkimi możliwymi ustawieniami
przełączników nie dają rezultatu. Jedyną możliwą metodą na naprawę którą
obecnie znam, to przepisanie zawartości tabel do nowego, świeżego pliku,
z pominięciem uszkodzonych tabel.

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ć.

Czy Firebird jest na jakimś podstawowym poziomie "felerny" i wrażliwy na
jakieś rzeczy typu antywirus?
Czy ja coś robię w programie bardzo niedobrego, typu "trzymasz
connection do bazy otwarty cały czas? nie idź tą drogą!"

Dodam, że używam IBX, i, niestety, Firebird "udaje" Interbase'a za
pomocą generowania gds32.dll. Delphi XE6, o ile to ma znaczenie.

Wszelkie rady, sugestie, opinie bardzo chętnie poznam.

--
Pozdrawiam,
Stregor

[miab]

W dniu 2015-02-03 o 08:35, Stregor pisze:

A co się dzieje z taką bazą jak zrobisz?:
gfix -user SYSDBA -password masterkey database -sweep

miab

[miab]

W dniu 2015-02-03 o 08:35, Stregor pisze:

> Wszelkie rady, sugestie, opinie bardzo chętnie poznam.
>

Jeszce jedno. Zdaje się ze w Windows XP pliki z rozszerzeniem .gdb
należały do puli specjalnie chronionych (backupowanych) przez system
przy zmianach i albo trzeba było zmienić strategię Windows albo
rozszerzenie na obojętne dla systemu.

miab

[Stregor]

> A co się dzieje z taką bazą jak zrobisz?:
> gfix -user SYSDBA -password masterkey database -sweep

Ciężko powiedzieć.
Mam jedną konkretną bazę teraz, która tak padła, i nią się posłużę jako
przykład.
Plik .fdb zmniejsza się z 1.4GB! do 1.25GB - ta sama baza, przepisana do
nowego pliku, ma 170MB.

Poza tym różnic nie widzę - dostęp do niektórych tabel pozostaje
koszmarnie długi, na przykład pusta tabela zamówienia - odczyt struktury
z tabel systemowych + odczyt danych (0 wierszy) to jakieś 30 sekund.
Zrobienie na takiej bazie gbak/grestore nic nie zmienia.

Sam stosuję taką "standardową" metodę naprawczą:
gfix %1 -validate -full -user SYSDBA -password masterkey
gfix %1 -mend -user SYSDBA -password masterkey
gbak %1 %1_ -b -g -user SYSDBA -password masterkey
gbak -c %1_ %1__ -user SYSDBA -password masterkey

jednak na "puchnącą" bazę nie przynosi ona efektów.

--
Pozdrawiam,
Stregor

[Stregor]

> Jeszce jedno. Zdaje się ze w Windows XP pliki z rozszerzeniem .gdb
> należały do puli specjalnie chronionych (backupowanych) przez system
> przy zmianach i albo trzeba było zmienić strategię Windows albo
> rozszerzenie na obojętne dla systemu.

Moje bazy mają rozszerzenie .fdb


--
Pozdrawiam,
Stregor

[miab]

W dniu 2015-02-03 o 10:05, Stregor pisze:

Rozumiem ze próbowałeś z różnymi wersjami FB2.5x z w miarę aktualnym
snapshotem 2.54 włącznie?

miab

[Tomek D]

W dniu 2015-02-03 o 08:35, Stregor pisze:

Jak ustawione ForcedWrites?
Osobiście nigdy nie miałem takich problemów, a bazy mam o rozmiarach
powyżej 100GB, ale wydaje mi się, że już gdzieś czytałem o takim problemie.

Tomek D.

[zpksoft]

W dniu wtorek, 3 lutego 2015 08:35:57 UTC+1 użytkownik Stregor napisał:
>...

Moje sugestie:
- w firewallu ustaw pełne prawa dla serwera Firebird (przy puszczonym tylko porcie 3050 może być blokowanie alertów- porty losowe)
- codziennie sweep (jak napisał miab)
- zmień rozszerzenie pliku bazy na inne, najlepiej w trybie awaryjnym
- dodaj do wyjątków nieindeksowanie w systemie plików z Twoim rozszerzeniem
- to samo w systemowym mechanizmie kopii/przywracania

Żeby oczyścić obecną bazę zrób backup -g i przywróć ją.

Paweł

[R.e.m.e.K]

Dnia Wed, 4 Feb 2015 00:53:55 -0800 (PST), zpksoft napisał(a):

> Moje sugestie:
> - w firewallu ustaw pełne prawa dla serwera Firebird (przy puszczonym tylko porcie 3050 może być blokowanie alertów- porty losowe)

Serio sugerujesz, ze plik baszy uszkadza sie bo firewall blokuje jakis fikcyjny port?

> - codziennie sweep (jak napisał miab)

Czy fundacja Firebird tez daje tak durne rady?

> - zmień rozszerzenie pliku bazy na inne, najlepiej w trybie awaryjnym

Ma .fdb, co jest zlego w tym rozszerzeniu? I na jakie ma zmienic wg Ciebie?

> - dodaj do wyjątków nieindeksowanie w systemie plików z Twoim rozszerzeniem

Indeksowanie systemowe nie uszkadza plikow. Poza tym plik bazy jest otwarty w trybie
wylacznosci zapisu.

> - to samo w systemowym mechanizmie kopii/przywracania

co to samo?


Mam wrazenie, ze to rady nas zasadzie "nie mam pojecia jak to wszystko dziala, ale na
wszelki wypadek sie pomodle".

--
pozdro
R.e.m.e.K

[J-23]

W dniu 03.02.2015 o 08:35, Stregor pisze:

Za to że jest duży plik bazy fireberda pomimo ilości danych odpowiada
jego garbage collection. A mianowicie baza jest tak zbudowana że alokuje
dość dużą ilość pamięci w stosunku do ilości danych.

Pomimo że np wyrzucimy część danych z bazy wielkość pliku albo się nie
zmniejszy wcale albo zrobi to nie znacznie. Powodem tego jest to że
Fireberd oznacza te miejsca jako puste nie zmniejszając pliku tak by
zapewnić mu szybszy dostęp do zapisu nowych danych.

Co do typowo Twojego problemu to będzie ciężko coś konkretnego doradzić
odnośnie zwalniania bo nie wiadomu w jaki sposób i jakie dane
przechowujesz w problematycznych tabelach. Sprawdź czy masz dobrze
indeksy na początek w tych tabelach porobione.

Puchnięciem bazy bym się nie przejmował bo to nie to jest Twoim problemem.



Ja mam obecnie bazy po 750 GB

Pozdrawiam

[ALO]

Użytkownik "Stregor" <str...@wytnij.to.gmail.com> napisał w wiadomości
news:54d07a5b$0$2184$6578...@news.neostrada.pl...

> Cześć.
>
> Spotkał się ktoś z Was z takim zjawiskiem?

Nie

> FB 2.5, baza > 100 tabel. Działa sobie normalnie, do pewnego czasu, a
> nagle zaczyna "dziczeć" - wielkość pliku .fdb rośnie bardzo szybko, tak
> samo wielkość .fbk. Zwykle wygląda to tak, że jedna (lub kilka) z tabel
> jest "pompowana" zerami lub losowymi znakami, ale tylko w pliku.

Co to znaczy "...ale tylko w pliku .." w jakim pliku, a gdzie jeszcze można
"pompować"?

> 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.

Poprosze plan tego selecta. Ile tabela ma rekordów?

>
> Problem potęgowany jest faktem, że taka baza może być użytkowana jeszcze
> czasem przez długi czas, aż dostęp do niej stanie się całkowicie
> niemożliwy. I wtedy okazuje się, że na przykład kopie zapasowe też są
> błędne - już od roku...
>
> Sztuczki typu gbak/grestore z wszelkimi możliwymi ustawieniami
> przełączników nie dają rezultatu.

Niby czemu miałyby dać jakiś rezultat, baza nie ma "pustych" obszarów tylko
tabele wypełnione być może zerami ale zera są tak samo poprawne jak jedynki.

> Jedyną możliwą metodą na naprawę którą obecnie znam, to przepisanie
> zawartości tabel do nowego, świeżego pliku, z pominięciem uszkodzonych
> tabel.

A te dane z uszkodzonych tabel nie są nikomu potrzebne?

> 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ć.

Co jest przypadkiem? Klient używający bazy (gratuluje kilku tysięcy
klientów).

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

Tak bym obstawiał, sprawdź wszystkie triggery zapisujące do inkryminowanych
tabel.

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

-mh

[Stregor]

> Rozumiem ze próbowałeś z różnymi wersjami FB2.5x z w miarę aktualnym
> snapshotem 2.54 włącznie?

Nie, nie próbowałem. U siebie mam najnowszą wersję 2.5.3, klienci mają
od 2.1 do 2.5.x

--
Pozdrawiam,
Stregor

[Stregor]

> Jak ustawione ForcedWrites?

włączone

> Osobiście nigdy nie miałem takich problemów, a bazy mam o rozmiarach
> powyżej 100GB, ale wydaje mi się, że już gdzieś czytałem o takim problemie.

Byłbym Ci wdzięczny za odkopanie tej informacji :)

--
Pozdrawiam,
Stregor

[Stregor]

> Za to że jest duży plik bazy fireberda pomimo ilości danych odpowiada
> jego garbage collection. A mianowicie baza jest tak zbudowana że alokuje
> dość dużą ilość pamięci w stosunku do ilości danych.

> Pomimo że np wyrzucimy część danych z bazy wielkość pliku albo się nie
> zmniejszy wcale albo zrobi to nie znacznie. Powodem tego jest to że
> Fireberd oznacza te miejsca jako puste nie zmniejszając pliku tak by
> zapewnić mu szybszy dostęp do zapisu nowych danych.

Wiem. Ale tu nie chodzi o normalny rozmiar bazy danych która sobie
powoli rośnie, i nie zmniejsza się przy usuwaniu rekordów. Chodzi o
nagły, niekontrolowany rozrost, najczęściej wygląda to tak, że jakieś
pole memo oprócz normalnego tekstu ma tonę śmiecia na końcu tegoż, i ta
tona się rozrasta w dziesiątki ton.

Spotkałem nawet rozwalone w ten sposób systemowe pole field description...

> Co do typowo Twojego problemu to będzie ciężko coś konkretnego doradzić
> odnośnie zwalniania bo nie wiadomu w jaki sposób i jakie dane
> przechowujesz w problematycznych tabelach. Sprawdź czy masz dobrze
> indeksy na początek w tych tabelach porobione.

Problem występuje w różnych tabelach, posiadających indeksy jak i nie
posiadających, a nawet w słownikach wewnętrznych mających na przykład
stałą i w zasadzie niezmienialną liczbę wierszy

> Puchnięciem bazy bym się nie przejmował bo to nie to jest Twoim problemem.

Jest moim problemem, bo:
a) na początku objawia się znacznym spowolnieniem tworzenia kopii zapasowej
b) później zwalniają podstawowe operacje na bazie - selekty, inserty
c) później baza pada, w momencie gdy uszkodzony zostaje obszar struktury

powtarzam, to nie jest normalny rozrost spowodowany eksploatacją /
dokładaniem danych. To jest "puchnięcie", jak komórki rakowe :)

--
Pozdrawiam,
Stregor

[Stregor]

>> FB 2.5, baza > 100 tabel. Dzia�a sobie normalnie, do pewnego czasu, a
>> nagle zaczyna "dzicze�" - wielko�� pliku .fdb ro�nie bardzo szybko, tak
>> samo wielko�� .fbk. Zwykle wygl�da to tak, �e jedna (lub kilka) z tabel

>> jest "pompowana" zerami lub losowymi znakami, ale tylko w pliku.
>

> Co to znaczy "...ale tylko w pliku .." w jakim pliku, a gdzie jeszcze mo�na
> "pompowa�"?

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.

>> 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.
>

> Poprosze plan tego selecta. Ile tabela ma rekord�w?

Tabel jest > 100, tabele mają rekordów od 0 (sic!) do dziesiątek
tysięcy. 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"

> Niby czemu mia�yby da� jaki� rezultat, baza nie ma "pustych" obszar�w tylko
> tabele wype�nione by� mo�e zerami ale zera s� tak samo poprawne jak jedynki.

Jeśli uszkodzone byłyby na przykład transakcje w limbo, wtedy
gbak/grestore by je pominął i obszar bazy by się zmniejszył. Lub z kilku
innych przyczyn, niestety tak się nie dzieje.

> A te dane z uszkodzonych tabel nie s� nikomu potrzebne?

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

>> 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�.
>
> Co jest przypadkiem? Klient u�ywaj�cy bazy (gratuluje kilku tysi�cy
> klient�w).

Tak. I dziękuję.

>> Czy ja co� robi� w programie bardzo niedobrego, typu "trzymasz connection
>> do bazy otwarty ca�y czas? nie id� t� drog�!"
>
> Tak bym obstawia�, sprawd� wszystkie triggery zapisuj�ce do inkryminowanych
> tabel.
>
> 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ć

P.S. ustaw sobie stronę kodową w czytniku :)

--
Pozdrawiam,
Stregor

[Eugeniusz Rink]

W dniu 04.02.2015 o 14:47, Stregor pisze:

>>> FB 2.5, baza > 100 tabel. Dzia�a sobie normalnie, do pewnego czasu, a
>>> nagle zaczyna "dzicze�" - wielko�� pliku .fdb ro�nie bardzo szybko, tak
>>> samo wielko�� .fbk. Zwykle wygl�da to tak, �e jedna (lub kilka) z tabel
>>> jest "pompowana" zerami lub losowymi znakami, ale tylko w pliku.
>>

Rozumiem, że HDD sprawdzony pod kątem błędów??
RAM również OK??

Proszę podać na jakim OS zainstalowana jest usługa serwera bazy danych FB.


Pozdrawiam

Eugeniusz Rink

[ALO]

> 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

[wloochacz]

W dniu 2015-02-03 o 08:35, Stregor pisze:
/ciach/

> Czy Firebird jest na jakimś podstawowym poziomie "felerny" i wrażliwy na
> jakieś rzeczy typu antywirus?
> Czy ja coś robię w programie bardzo niedobrego, typu "trzymasz
> connection do bazy otwarty cały czas? nie idź tą drogą!"

Connection nie, ale transakcje - jak najbardziej.
Ale tylko jeśli używasz CommitRetaining i/lub dugo wiszacych transkacji
na dociążonej bazie.
A jeśli używasz np. IBX (bo takie użycie zatwierdzania transakcji jest
tam jest wygodne, bo IBX nie zamyka DSu po Commit transakcji), to pewnie
tak masz to zrobione.
http://www.firebirdsql.org/file/documentation/papers_presentations/html/paper-fbent-impacting.html

Jest jedno małe "ale" - sweep powinien to posprzątać, a twierdzisz ze
tak się nie dzieje...
Ciekawe.

A jeszcze jedno (to będzie sugestia a nie rozwiązanie problemu) - nie
używasz czasem Rollback tam, gdzie nie powinieneś? Np. zmieniasz dane, a
potem user mowie - nie, nie potwierdzam zmian.
I teraz tak - jeżeli dane faktycznie nie zostały zmienione w bazie, nie
rób rollback w takim przypadku. Rob Commit - a najlepiej w powiązaniu z
CachedUpdates; ale to na przyszłość ;-)
http://www.firebirdsql.org/manual/gfix-housekeeping.html

> Dodam, że używam IBX, i, niestety, Firebird "udaje" Interbase'a za
> pomocą generowania gds32.dll. Delphi XE6, o ile to ma znaczenie.
>
> Wszelkie rady, sugestie, opinie bardzo chętnie poznam.

Przeczytałem w tym wątku tyle bzdur, ze głową mala... Co nowy post tym
większe "zrozumienie" tematu ;-)
Ale ubawiłem się setnie - dzięki Panowie! :)

--
wloochacz

[zpksoft]

W dniu środa, 4 lutego 2015 10:49:33 UTC+1 użytkownik R.e.m.e.K napisał:
> Dnia Wed, 4 Feb 2015 00:53:55 -0800 (PST), zpksoft napisał(a):
>
> > Moje sugestie:
> > - w firewallu ustaw pełne prawa dla serwera Firebird (przy puszczonym tylko porcie 3050 może być blokowanie alertów- porty losowe)
>
> Serio sugerujesz, ze plik baszy uszkadza sie bo firewall blokuje jakis fikcyjny port?
>

Skoczyłeś mi kolego na plecy, widać niektórzy tak mają. Nie lubię z takimi gadać, ale tu zrobię wyjątek. Zakładam że masz niewielką wiedzę.

Niczego nie sugeruję a to o czym piszę wynika z moich długoletnich doświadczeń z Firebirdem. Nie dalej jak w ubiegłym tygodniu jeden z klientów powymieniał komputery i raptem program zaczął się zacinać i wolno pracować mmimo lepszego sprzętu. To był właśnie ten przypadek. To nie jest żaden fikcyjny tylko losowy port.

> > - codziennie sweep (jak napisał miab)
>
> Czy fundacja Firebird tez daje tak durne rady?
>

Co jest durnego w czyszczeniu bazy z zawieszonych transakcji? Jeżeli jest jakaś przeszkoda w sieci (a tak sądzę) to należy do czasu normalizacji robić to ręcznie. Firebird sam wykonuje tę operację co pewien czas. Być może w pliku konfiguracyjnym Firebirda można ten interwał ustawić. nie sprawdzałem.

> > - zmień rozszerzenie pliku bazy na inne, najlepiej w trybie awaryjnym
>
> Ma .fdb, co jest zlego w tym rozszerzeniu? I na jakie ma zmienic wg Ciebie?
>

Poczytaj, chyba miab o tym wspomniał. Dodatkowo polecam Google. Ja już lata temu przyjąłem rozszerzenie .zpk

> > - dodaj do wyjątków nieindeksowanie w systemie plików z Twoim rozszerzeniem
>
> Indeksowanie systemowe nie uszkadza plikow. Poza tym plik bazy jest otwarty w trybie
> wylacznosci zapisu.
>
> > - to samo w systemowym mechanizmie kopii/przywracania
>
> co to samo?
>

Ech, poczytaj na MSDN-ie co system robi na plikach które uważa za ważne żeby je chronić i szybko przywrócić na wypadek awarii. Widzę, że ten temat jest dla Ciebie obcy.

>
> Mam wrazenie, ze to rady nas zasadzie "nie mam pojecia jak to wszystko dziala, ale na
> wszelki wypadek sie pomodle".
>

Nie zaszkodzi.

> --
> pozdro
> R.e.m.e.K

Paweł

[R.e.m.e.K]

Dnia Thu, 5 Feb 2015 00:22:50 -0800 (PST), zpksoft napisał(a):

>>> Moje sugestie:
>>> - w firewallu ustaw pełne prawa dla serwera Firebird (przy puszczonym tylko porcie 3050 może być blokowanie alertów- porty losowe)
>>
>> Serio sugerujesz, ze plik baszy uszkadza sie bo firewall blokuje jakis fikcyjny port?
>
> Skoczyłeś mi kolego na plecy, widać niektórzy tak mają. Nie lubię z takimi gadać, ale tu zrobię wyjątek. Zakładam że masz niewielką wiedzę.

Wiedze mam niewielka, to prawda. Pytania jaka Ty masz w takim razie? :-)

> Niczego nie sugeruję a to o czym piszę wynika z moich długoletnich doświadczeń z
> Firebirdem. Nie dalej jak w ubiegłym tygodniu jeden z klientów powymieniał komputery i
> raptem program zaczął się zacinać i wolno pracować mmimo lepszego sprzętu. To był
> właśnie ten przypadek. To nie jest żaden fikcyjny tylko losowy port.

I czego dowiodles tym przykladem? Ze plik bazy sie uszkadza? Nie rozbawiaj mnie bardziej
niz juz to czyniles :-)
Z moja skromna niewiedza wiem, ze Firebird uzywa do komunikacji portu 3025 (standardowo)
oraz JESLI uzywa sie eventow to dodatkowo korzysta z portu losowego. Mozna ten losowy port
ustawic w pliku konfiguracyjnym na konkretny port (remoteauxport), ale standardowa
instalka tego nie robi.
Jednakowoz blokowanie tego portu NIE USZKADZA BAZY.
Poczytaj i doucz sie:

http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf

>>> - codziennie sweep (jak napisał miab)
>>
>> Czy fundacja Firebird tez daje tak durne rady?
>
> Co jest durnego w czyszczeniu bazy z zawieszonych transakcji?

Durne jest czyszczenie bazy codziennie.

> przeszkoda w sieci (a tak sądzę) to należy do czasu normalizacji robić to ręcznie.
> Firebird sam wykonuje tę operację co pewien czas. Być może w pliku konfiguracyjnym
> Firebirda można ten interwał ustawić. nie sprawdzałem.

Poza tym sweep nie czysci "zawieszonych transakcji", to troche bardziej zlozone, zeby to
zakumac musialbys wiedziec co to MGA, ale... ze mimo niewiedzy mam nadal dobre serce to
dam Ci szanse, czytaj:

http://ibexpert.net/ibe/index.php?n=Doc.Multi-generationalArchitectureMGAAndRecordVersioning

>>> - zmień rozszerzenie pliku bazy na inne, najlepiej w trybie awaryjnym
>>
>> Ma .fdb, co jest zlego w tym rozszerzeniu? I na jakie ma zmienic wg Ciebie?
>
> Poczytaj, chyba miab o tym wspomniał. Dodatkowo polecam Google. Ja już lata temu przyjąłem rozszerzenie .zpk

No wlasnie, moze poczytaj? Z moja niewielka wiedza wiem, ze problem byl z rozszerzeniem
gdb a nie fdb, ale moze Ty "masz inne doswiadczenia". Zatem jak radzisz to czytaj:

"Naming databases on Windows

Note that the recommended extension for database files on Windows ME and XP is ".fdb" to
avoid possible conflicts with "System Restore" feature of these Windows versions. Failure
to address this issue on these platforms will give rise to the known problem of delay on
first connection to a database whose primary file and/or secondary files are named using
the ".gdb" extension that used to be the Borland convention for suffixing InterBase
database file names."

>>> - dodaj do wyjątków nieindeksowanie w systemie plików z Twoim rozszerzeniem
>>
>> Indeksowanie systemowe nie uszkadza plikow. Poza tym plik bazy jest otwarty w trybie
>> wylacznosci zapisu.
>>
>>> - to samo w systemowym mechanizmie kopii/przywracania
>>
>> co to samo?
>>
>
> Ech, poczytaj na MSDN-ie co system robi na plikach które uważa za ważne żeby je chronić i szybko przywrócić na wypadek awarii. Widzę, że ten temat jest dla Ciebie obcy.

No to jak juz poczytasz i po'ech'ujesz przed lustrem to wroc i przyznaj, ze Twoj post byl
belkotliwy i chaotyczny, ze cos tam gdzies slyszales, cos widziales, ale co... bylo za
ciemno i nie pamietasz.

>> Mam wrazenie, ze to rady nas zasadzie "nie mam pojecia jak to wszystko dziala, ale na
>> wszelki wypadek sie pomodle".
>>
>
> Nie zaszkodzi.

Tak mylalem... od takiego programowania to kolana moga Ci wysiasc ;-)

--
pozdro
R.e.m.e.K

[R.e.m.e.K]

Dnia Thu, 5 Feb 2015 11:36:30 +0100, R.e.m.e.K napisał(a):

> ze Firebird uzywa do komunikacji portu 3025 (standardowo)

oczywiscie literowka: port 3050

--
pozdro
R.e.m.e.K