RSS Feed

‘bazy danych’ Category

  1. Firebird, restore bazy i błąd „gbak: ERROR: could not find table/procedure for GRANT”

    Styczeń 22, 2014 by 0verlord

    Jeżeli przy odtwarzaniu bazy Firebirda dostajemy taki błąd jak w temacie, oznacza to, że nastąpiła korupcja 😉 . A dokładniej skorumpowała nam się baza security2.fdb.
    Jeżeli nie robiliście backupu, to trzeba sobie taką wypakować z instalatora i następnie dodać odpowiednich userów przy pomocy polecenia gsec.

    Log z próby
    gbak: restoring privilege for user SYSDBA
    gbak: ERROR:action cancelled by trigger (0) to preserve data integrity
    gbak: ERROR: could not find table/procedure for GRANT
    gbak: Exiting before completion due to errors


  2. Firebird fb_shash 1.0 – ściągnij stąd.

    Październik 21, 2013 by 0verlord

    Jest taki UDF do Firebirda, nazywa się jak w temacie, shash. Ale ostatnio zniknął z sajta producenta. Dlatego też możesz go ściągnąć stąd. Jest poczyszczony z objectów i binarek na tyle, ile miałem mocy przerobowych. Na zdrowie zatem.


  3. Diagnozowanie podstawowych problemów z wydajnością bazy Firebird

    Marzec 26, 2013 by 0verlord

    firebird logo

    O bazie Firebird już pisałem, konkretnie w tym poście, gdzie to jest wyjaśnione, po co należy robić gbak i odgbak (tj restore). A dzisiaj będzie o przypadku z życia i o tym, jak taki przypadek wyeliminować.

    Baza po jakimś czasie zaczęła zamulać. Proste zapytanie trwały nawet i kilkadziesiąt sekund. Przy okazji podstroiłem Apacha pod kątem wydajności, bo najpierw miałem niecne podejrzenie, że to właśnie tutaj jest problem. Po poprawkach w konfigu, firebird zaczął chodzić jakieś 30% szybciej, ale zamuła dalej była odczuwalna.

    Po konsultacji z mistrzami wymiataczami, został zarządzony gbak/restore bazy. Dla porządku, baza to Firebird SuperServer, w wersji 2.5.1, a wirtualizacja jest na LXC.

    Po restore, poprzednia prędkość bazy wróciła do normy, co kazało mi odświeżyć sobie info o poście, który wspominałem na początku wpisu. Jeżeli baza wróciła do siebie po restore, to znaczy, że nie zadziałało czyszczenie.

    W cronie regułka była – ale na wszelki wypadek ją odpaliłem z konsoli. Zapytała o usera i hasło do bazy… #fail.
    A to znaczyło, że sweep się nie wykonał, i baza nabrała rozmaitego śmiecia. Te śmieci wyczyścił gbak/restore. Co ciekawe, na innym serwerze mam dokładnie taką samą regułkę – i tam to działa (tak, sprawdziłem dzisiaj). Różnica jest tylko taka, że tam jest Classic, a na wirtualce SuperServer. Kocham takie niespójności…

    Przy okazji, taki problem można zdiagnozować szybciej, przy pomocy polecenia ‚gstat’.
    Na customowej instalacji z tarballa w Debianie, gstat jest tu: /opt/firebird/bin/gstat.
    Uruchamiamy go z parametrem -h i ścieżką do pliku bazy, np. tak:

    /opt/firebird/bin/gstat -h /var/db/bla.fdb

    Powinien pokazać coś podobnego do tego:


    Database "/var/db/bla.fdb"
    Database header page information:
    Flags 0
    Checksum 12345
    Generation 51183
    Page size 4096
    ODS version 11.2
    Oldest transaction 51141
    Oldest active 51142
    Oldest snapshot 51142
    Next transaction 51143
    Bumped transaction 1
    Sequence number 0
    Next attachment ID 104
    Implementation ID 19
    Shadow count 0
    Page buffers 21480
    Next header page 0
    Database dialect 3
    Creation date Mar 26, 2013 21:50:48
    Attributes

    Variable header data:
    Sweep interval: 0
    *END*

    Co nas interesuje z tej listy? Sweep interval – tutaj ustawiony na 0, czyli jak się można domyślić – jest wyłączony. Interesuje nas jeszcze ODS version (czyli on-disk structure), bo to pokazuje, która wersja bazy danych odczyta nasz plik z bazą. Na szczęście w przypadku pomylenia wersji, dostaniemy odpowiedni komunikat, że ODS jest niezgodny.
    Interesuje nas też konkretnie ta sekcja:
    Oldest transaction 51141
    Oldest active 51142
    Oldest snapshot 51142
    Next transaction 51143

    Tutaj mamy numerki, a żeby baza dobrze chodziła, różnica pomiędzy nimi nie może być większa niż 100, lub w innych manualach 200.
    Można to bardzo prosto sprawdzić – wystarczy przez jakiś czas nie włączać sweepa, potem go włączyć i zobaczyć.
    Z punktu wydajnościowego interesuje nas jeszcze parametr „Page buffers” – dla superservera z 4 GB ramu powinien być właśnie na takim poziomie jak u mnie. Ale np. w wersji Firebird Classic, wartość 5000 jest sensowna.

    Podsumowując,


  4. Firebird, gfix shutdown full, online i database shutdown

    Luty 9, 2013 by 0verlord

    Bardziej pisze tego posta ku pamięci własnej, a sytuację z Firebirdem miałem następującą:

    Firebird to taka baza, której od czasu do czasu trzeba zrobić backup i odtworzenie z niego bazy z kilku powodów:
    1. garbage collector przy backupie czyści fizycznie plik bazy ze zwolnionych stron, i z nieużywanego śmietnika – wtedy baza robi się mniejsza.
    2. jeżeli na bazie zachodzi sporo poprawek, może się okazać, że np. baza sobie chodzi, ale przy próbie jej odtworzenie dostaniemy konflikt np. na kluczach obcych, i może się okazać, że trzeba poprawiać ręcznie backup, żeby cokolwiek odtworzyć
    3. z jakiegoś dziwnego powodu, baza chodzi wydajniej po backupie/restore.

    Stąd też u klienta zaszła konieczność backup/restore bazy.
    Baza Firebirda na 4 tryby działania: normal, multi, single i full.
    Przełączanie się między nimi robi się przy pomocy gfixa i opcji -online i -shutdown. Żeby można było bez zgrzytu przegrywać sobie plik bazy, trzeba bazę przełączyć z tryb shutdown. I tak zrobiłem.
    gfix -shut fill -force 0 /plik/bazy.fdb
    Baza się zamknęła, połączenia teoretycznie zostały zakończone. Ubiłem fb_inet_servery (Firebird jest w wersji classic) i zdownowałem xinetd’a. Plik wrzuciłem na storage w stanie jakim był i chciałem zrobić gbaka. Baza po
    gfix -online normal /plik/bazy.fdb powiedziała, że baza jest shutdown. Que pasa? No więc po serii strace’ów okazało się, że wisi mi jeden proces fb_inet_server, który oparł się killallowi. Ubiłem go i baza wróciła.

    Potem znalazłem jeden post na serverfaulcie, z którego wynika, że takie rzeczy potrafią się dziać, jeżeli nie została zakończona jakaś transakcja. Ale dlaczego ta transakcja nie zareagowała na -online single a potem na -shut full ? Kto to wie.

    Czy ja już wspominałem, jak nie lubię firebirda? 😉


  5. Instalacja Symfony z Postgresem na hostingu nazwa.pl

    Styczeń 28, 2012 by 0verlord

    W skrócie, da się, chociaż obiłem się o kilka problemów.

    Z wrzuceniem witryny do katalogu nie ma problemu, załatwiamy wszystko z activeadmina. Panel jest na tyle sensowny, że nie przygniata i szybko można go ogarnąć.

    Problemy:

    1. Trzeba dobrze uważać przy tworzeniu bazy, bo konfigurator może nas obdarzyć niestandardowym portem Postgresa. Ja dostałem np. 5443 zamiast domyślnego 5432. Objawia się to tak, że mimo, wydawałoby się, poprawnie skonfigurowanych parametrów w databases.yml dostajemy Permission Denied.

    2. Nasz katalog domowy, a co za tym idzie katalog, w którym siedzi Symfony, a który należy podać w ProjectConfgurationClass.php wygląda jakoś tak: /home/<nazwa konta>/ftp/. Jak sprawdzić, jak wygląda nasz katalog? Najlepiej wrzucając do katalogu przeznaczonego na witrynę prosty „skrypcik” w php, który nam pokaże co trzeba. Wygląda on np. tak:
    <?php
    echo getcwd() . "\n";
    ?>

    I ładnie pokazuje odpowiedni katalog.

    3. Błędy. Jak na każdym hostingu, nie mamy dostępu do logów serwera www, a czasem wersje _dev aplikacji nie wystarczają, żeby pokazać cokolwiek sensownego i naprowadzającego na właściwy błąd. Na nazwie można to zrobić, podając do pliku .htaccess w głównym katalogu projektu takie wpisy:

    php_value display_errors 1
    php_value display_startup_errors 1
    php_value display_errors On
    php_value error_reporting E_ALL
    php_value error_log /katalog/projektu/symfony/web/error.log

    Co to robi? Włącza raportowanie php, domyślnie wyłączone na nazwie. Oczywiście należy to zakomentować jak już postawimy aplikację w całości, żeby niepotrzebnie nie pokazywać błędów. Ale wyjaśnienia wymaga jeszcze ostatnia linijka, ta ze ścieżką.
    Chodzi tutaj o to, żeby stworzył się log w katalogu domyślnie widocznym pod główną domeną, żeby można było na osobnej zakładce oglądać błędy. Ten katalog trzeba dopasować do tego, co pokazuje php z punktu nr 2. Jeżeli ktoś pomyli ścieżki, i plik nie będzie widoczny z sieci, zawsze można go pobrać przez ftp. Ciężko dostępny log dalej loguje, i jest lepszy niż brak logów w ogóle.

    To, że dało się włączyć logowanie, to całkiem ciekawy ficzers nazwy. Na home.pl taka sztuczka raczej by nie przeszła, ale i nie sprawdzałem. Na home.pl natomiast jest inny problem z symfony, opisany dokładnie tutaj.


  6. Vtiger 5.3, instalacja na home.pl i błąd przy logoucie

    Grudzień 10, 2011 by 0verlord

    Stawiam Vtigera 5.3 dla klienta. Pierwszy zgrzyt, to home.pl, ale poradziłem sobie łopatologicznie, tj. upload pliku do katalogu, phpshell i unzip. PHPShell, bo z jakiegoś powodu zapychanie plików po ftp na home.pl działa koszmarnie wolno. Tj. jak pcham jeden wielki plik, to bez problemów, pcha się błyskawicznie. Natomiast zapchanie archiwum pełnego małych pliczków trwa wieki.

    Instalator vtigerowy można sobie z miejsca odpuścić. Nie zadziała z kilku powodów:
    1. nie umie stworzyć bazy, co bym nie zmieniał i tak przerywa w połowie. Internet sugeruje wiele rozwiązań – w wersji 5.3 żadne mi nie zadziało.
    2. z jakiegoś powodu wykrywa katalog główny jako // (dwa slashe), potem próbuje czytać z tego katalogu, a że go nie znajduje – rzuca błędem. Konkretnie $root_directory = '/';
    3. defaultowo w podkatalogu nie ma katalogu tmp. Trzeba dodać. Ale jeżeli się tego nie walczyło z home.pl to się tego nie wie, więc instalator się wywali.

    Proponuję zatem rozwiązanie następujące:
    1. zainstalować sobie na normalnym linuxie i uruchomić instalator.
    2. odpowiedzieć na wszystkie pytania i skonfigurować sobie instalkę
    3. na home.pl wypakować czystą wersję i odpowiednio spreparować config.inc.php
    4. wgrać dumpa ze świeżej instalki, ale nie przez phpmyadmina (czyli przez web), bo też mi się to nie udało – import pluł, że plik jest za duży. Za duży, pewnie. 750kb to za dużo.
    5. skopiować pliki z lokalnej instalki:
    tabdata.php parent_tabdata.php user_privileges/sharing_privileges_cyferka.php i user_privileges/user_privileges_cyferka.php – jak tego nie skopiujemy, dostaniemy komunikat o braku któregoś z nich, najczęściej z numerkiem 1.
    6. odpalić i tadam.wav

    No i generalnie będzie działać, z kilkoma wyjątkami. Nie da się wylogować, bo się wysypie i kilka modułów administracyjnych też nie będzie działać – np. edytor konfiguracji. Przy logoucie error będzie wyglądał jak niżej:

    Warning: require_once(modules/VtigerBackup/VtigerBackup.php) [function.require-once]: failed to open stream: No such file or directory in /modules/Users/Logout.php on line 29

    Fatal error: require_once() [function.require]: Failed opening required 'modules/VtigerBackup/VtigerBackup.php' (include_path='/include/htmlpurifier/library:.:/:/usr/local/php/pear5') in /modules/Users/Logout.php on line 29

    i rzeczywiście – nie ma tego skrypciku.

    Tu mnie naprowadzili: http://forums.vtiger.com/viewtopic.php?t=40319

    Ten plik to jest część podstawowych modułów vtigera, i normalnie instalator je wypakowuje – o ile zakończy sukcesem cała akcję. Ale jak to zrobić na home?

    Curlftp naszym kolegą. Montujemy sobie katalog z witryną po ftpfs.
    Wypakowujemy sobie instalkę, wchodzimy do
    packages/vtiger/mandatory
    i to właśnie tam siedzi to, czego nam brakuje.
    Teraz część trudniejsza. Po odpakowaniu, archiwa z modułami zawierają dwa katalogi: modules i templates. Modulesy wypakowujemy do głównego katalogu ze stroną, a templates do ./Smarty/templates, wg schematu, np. dla ConfigEditor.
    ./Smarty/templates/modules/ConfigEditor/index.tpl
    Czyli w katalogu ./Smarty/templates/modules zakładamy katalog taki jak nazwa wypakowanego modułu.
    Można też prościej – w końcu instalowaliśmy lokalną wersję, żeby mieć bazę. Kopiujemy z lokalnie działającego vtigera katalog.
    Smarty/templates oraz
    modules/

    W końcu to te same pliki i ta sama wersja i tylko odpowiednio 2.3- i 20MB.

    Potem można sobie doinstalować np. polski język, np.stąd, ale to już po zalogowaniu przez managera modułów. Najlepiej zrobić to na końcu, ponieważ templejty, którymi będziemy mieszać, nadpisują niektóre pliki z tłumaczeniami.

    Amen.


  7. LMS i odzyskiwanie z backupu

    Grudzień 2, 2011 by 0verlord

    Sytuacja jak zazwyczaj: pada mi host z lmsem, backup się zrobił i odzyskał. Trzeba po prostu odzyskać, bez upgrade i innych takich tam sztuczek. No to jadę – przenoszę bazy, ale mysql < baza.sql rzuca permission denierem i wymaganiami super usera. Dokładnie takimi erorrami rzucało: Napotkano błędy w bazie danych!
    Zapytanie: CREATE FUNCTION lms_current_user() RETURNS int(11) NO SQL
    RETURN @lms_current_user;
    Błąd: You do not have the SUPER privilege and binary logging is enabled
    (you *might* want to use the less safe log_bin_trust_function_creators
    variable)
    Zapytanie: CREATE VIEW customersview AS SELECT c.* FROM customers c
    WHERE NOT EXISTS ( SELECT 1 FROM customerassignments a JOIN
    excludedgroups e ON (a.customergroupid = e.customergroupid) WHERE
    e.userid = lms_current_user() AND a.customerid = c.id)
    Błąd: FUNCTION lms.lms_current_user does not exist

    Przywróciłem bazę z doc/lms.mysql, ale nie pomogło, dalej pluło errorami z customerviewsem.
    Wujek google skierowął mnie tu.

    W skrócie: uwaliłem viewsy, wszystkie:
    CREATE VIEW nas AS
    SELECT n.id, inet_ntoa(n.ipaddr) AS nasname, d.shortname, d.nastype AS type,
    d.clients AS ports, d.secret, d.community, d.description
    FROM nodes n
    JOIN netdevices d ON (n.netdev = d.id)
    WHERE n.nas = 1;

    CREATE VIEW vnodes_mac AS
    SELECT nodeid, GROUP_CONCAT(mac SEPARATOR ',') AS mac
    FROM macs GROUP BY nodeid;

    CREATE VIEW vnodes AS
    SELECT n.*, m.mac
    FROM nodes n
    LEFT JOIN vnodes_mac m ON (n.id = m.nodeid);

    CREATE VIEW vmacs AS
    SELECT n.*, m.mac, m.id AS macid
    FROM nodes n
    JOIN macs m ON (n.id = m.nodeid);

    CREATE VIEW customersview AS
    SELECT c.* FROM customers c
    WHERE NOT EXISTS (
    SELECT 1 FROM customerassignments a
    JOIN excludedgroups e ON (a.customergroupid = e.customergroupid)
    WHERE e.userid = lms_current_user() AND a.customerid = c.id);

    i dodałem funkcję:
    CREATE FUNCTION lms_current_user() RETURNS int(11) NO SQL RETURN @lms_current_user;.

    Wszystko oczywiście po dodaniu bazy i usera do niej.Chciałem też odpowiednio okomentować w blogu z linka przydatne informacje, a tutaj niespodzianka:

    WordPress database error: [INSERT command denied to user 'xxx'@'localhost' for table 'wp_comments']

    Życie. Więc podziękuję tu:

    Thenks meeeen, I loveeee youuuuu 😀 (i napraw sobie zapomnianego worpdressa ;-))

    EDIT: wszystkie viewsy trzeba skasować, jak leci wszystkie, tj.

    DROP VIEW IF EXISTS nas;
    DROP VIEW IF EXISTS vnodes_mac;
    DROP VIEW IF EXISTS vnodes;
    DROP VIEW IF EXISTS vmacs;
    DROP VIEW IF EXISTS customersview;

    W sumie ciekawe, dlaczego dump nie odtworzył viewsów. Ale nie chce mi się szukać.


  8. Postgresql, lms.current_user i błąd

    Sierpień 19, 2011 by 0verlord

    Szybko o LMSie, postgresie i bugu będącego efektem niedoczytania konfiguracji.

    Dokumentacja mówi, żeby: Wymagane jest dodanie wpisu w postgresql.conf: custom_variable_classes = 'lms'

    Natomiast nie mówi, co się stanie, jeżeli tego wpisu nie będzie. Oczywiście, można z sourca wyczytać nie? 😛

    Efekt wygląda tak:
    Zapytanie: SELECT set_config('lms.current_user', '1', false)
    Błąd: BŁĄD: nierozpoznany parametr konfiguracyjny "lms.current_user"
    Zapytanie: SELECT COUNT(id) AS total, COUNT(CASE WHEN status = 3 THEN 1 END) AS connected, COUNT(CASE WHEN status = 2 THEN 1 END) AS awaiting, COUNT(CASE WHEN status = 1 THEN 1 END) AS interested FROM customersview WHERE deleted=0
    Błąd: BŁĄD: nierozpoznany parametr konfiguracyjny "lms.current_user"
    Zapytanie: SELECT SUM(a.value)*-1 AS debtvalue, COUNT(*) AS debt FROM (SELECT SUM(value) AS value FROM cash LEFT JOIN customersview ON (customerid = customersview.id) WHERE deleted = 0 GROUP BY customerid HAVING SUM(value) < 0 ) a
    Błąd: BŁĄD: nierozpoznany parametr konfiguracyjny "lms.current_user"

    Dodajemy wpis, o którym mowa w docku i error znika.


  9. Chef-server, vserver i losowe pady

    Sierpień 3, 2011 by 0verlord

    Do zarządzania windami i *nixami używamy od jakiegoś czasu chefa. Generalnie z powodu ogólnie znanego problemu nowoczesności stabilnych wersji Debiana, postawiliśmy testinga jako guesta.

    Pojawił się problem, serwer chefa umierał, i nawet na najwyższym poziomie debuga nie mówił dlaczego. Strace najlepszym naszym przyjacielem jeeest. Padało z powodu braku miejsca na /tmp.
    W defaultowej konfiguracji vservera, /tmp jest montowany jako filesystem tmpfs o rozmiarze 16mb. Trzeba było zwiększyć do 256m i problem się skończył. Na normalnych serwerach, ten problem by nigdy nie wystąpił, natomiast na vserverach, już jak najbardziej. Ciekawe, że do loga nie bluzga.

    Jak zwiększyć rozmiar katalogu /tmp w gueście? Zmieniamy plik fstab w katalogu konfiguracyjnym vservera. Ten plik najczęściej znajduje się w /etc/vservers/nazwa_vservera/fstab i wygląda tak:
    none /proc proc defaults 0 0
    none /tmp tmpfs size=16m,mode=1777 0 0
    none /dev/pts devpts gid=5,mode=620 0 0

    Wystarczy zastopować vserver, zmienić size=16m na np. size=256m i wystartować vserver od nowa.
    Tadam.wav.


  10. Backupninja 0.9.8, backup mysqla w vserverze i bug

    Kwiecień 27, 2011 by 0verlord

    Objawia się tak: mamy sobie głównego hosta, i kilka guestów (vserverów). Na jednym z nich chodzi mysql. Dodajemy akcję do backupninja przy pomocy helpera, żeby nam robił dumpa wszystkich baz. Konfiguracja z ninjahelperem jest banalna, więc ją pominę. Error w debugu wygląda np. tak dla losowej bazy:
    Debug: su root -c "/usr/sbin/vserver mysql exec /usr/bin/mysqldump --defaults-extra-file=/etc/mysql/debian.cnf --lock-tables --complete-insert --add-drop-table --quick --quote-names sugarcrm -r '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql'"
    Warning: mysqldump: Can't create/write to file '/home/vservers/mysql/var/backups/mysql/sqldump/sugarcrm.sql' (Errcode: 2)
    Warning: Failed to dump mysql databases sugarcrm

    Teraz ocb? Skrypt wykonujący backup, konkretnie ten (na Debianie):
    /usr/share/backupninja/mysql
    wydaje się nie zauważać, że wykonuje polecenie w środku vservera, więc nie ma tam katalogu podanego jako parametr do polecenia. To co widać powyżej, szuka katalogu
    /home/vservers/mysql/var/backups/mysql/sqldump
    ale w środku vservera, czyli jak byśmy zrobili na gueście katalog taki:
    /home/vservers/mysql/var/backups/mysql/sqldump
    widziany z poziomu maina jako
    /home/vservers/home/vservers/mysql/var/backups/mysql/sqldump
    to by się backup zrobił, ale szukać by go trzeba gdzie indziej.

    Jak to naprawić? Generalnie bez zagłębiania się w logikę kodu, i zdając sobie sprawę, że mogę popsuć coś innego, hackujemy sobie na szybko
    /usr/share/backupninja/mysql,
    linijka 287 i okolice.

    # Test to make sure mysqld is running, if it is not sqldump will not work
    $VSERVER $vsname exec su $user -c "$MYSQLADMIN $defaultsfile ping 2>&1 >/dev/null"
    if [ $? -ne 0 ]; then
    fatal "mysqld doesn't appear to be running!"
    fi
    if [ "$compress" == "yes" ]; then
    execstr="$VSERVER $vsname exec $DUMP | $GZIP $GZIP_OPTS > '$vroot$dumpdir/${db}.sql.gz'"
    else
    execstr="$VSERVER $vsname exec $DUMP -r '$vroot$dumpdir/${db}.sql'"
    fi
    else

    usuwamy ‚$vroot’ z linijek zaczynających się na execstr, i zostaje samo ‚$dumpdir’. czyli tutaj ‚/var/backups/mysql/sqldump’ czyli tak, jak ma być.
    I to wszystko. W ten sposób usuwamy /home/vservers z argumentu do vserver exec i już polecenie widzi odpowiedni katalog.

    Ciekawe, że nikt tego nie znalazł do tej pory, bo buga poprawiam drugi raz, pierwszy raz trafiłem go w Lenny’m i się pojawił po upgrade do Squeeze’a.