 |
|
|
 | Práva a jejich subjekty |  | Provoz a správa 602SQL serveru | Systémové triggery |  |
Činnost SQL serveru lze sledovat pomocí trasovacích nástrojů a zaznamenávat do textových souborů, kterým se říká logy. Takto lze získat:
Provozní správce databáze může určit, jaké informace se zaznamenávají do logu (s výjimkou trasování čtení a zápisu dat, což povoluje Bezpečnostní správce) - viz Administrování SQL serveru.
Pokud potřebujete sledovat více různých druhů informací, pak lze pro ně vytvořit samostatné logy. Každý log má svoje jméno, pro něž platí stejná omezení jako pro jména všech ostatních objektů ve 602SQL.
SQL server vždy automaticky vytváří tzv. základní log označený prázdným jménem. Další logy je třeba definovat a pak existují až do vypnutí serveru. Každý log se zaznamenává do jednoho textového souboru (mimo databázi). Základní log se zapisuje do souboru jménem wbsqllog.txt umístěného v adresáři specifikovaném v okně Správa databáze na záložce Soubory jako Základní log (standardně je to stejný adresář, v němž je databázový soubor). Soubory příslušné ostatním logům se zadávají při jejich definování.
Pokud při definování logu jeho soubor již existuje, bude se do něj zapisovat na konec. Pokud soubor neexistuje, je vytvořen.
Nový log lze definovat takto: z klientského prostředí otevřete okno Monitor pro daný server na záložce Trasování. Z popup menu kdekoliv v gridu záložky provedete příkaz Vytvořit nový dočasný log. Otevře se okno, v němž zadáte jméno logu, jméno a umístění souboru, do něhož se bude zapisovat a pokud má mít log jiný než defaultní formát, zadáte formát (popis formátu je uveden u funkce _sqp_define_log).
Nový log lze z programu definovat tak, že zavoláte standardní proceduru _sqp_define_log. Log smí definovat pouze provozní správce databáze.
Pokud potřebujete, aby se určitý log vytvářel při každém spuštění serveru, pak zařaďte volání funkce _sqp_define_log do systémového triggeru na start serveru (_on_server_start).
Při dlouhodobém extenzivním logování mohou logové soubory být poměrně velké a nepřehledné. SQL server umí založit nový logový soubor pro každý den. Tuto vlastnost lze zapnout pomocí vlastnosti DailyBasicLog pro základní log a pomocí DailyUserLogs pro ostatní logy.
Je-li tato vlastnost zapnuta, pak server při otevírání logu připojí na konec jeho jména (před případnou příponu) datum ve tvaru RRMMDD. O půlnoci každého dne přejde na nový logový soubor. Například log se jménem SQLLOG ze dne 19.4.2003 bude implicitně v souboru SQLLOG030419.txt.
Server provádí logování své činnosti v souladu se zadanými požadavky na logování. Požadavek platí, dokud není zrušen nebo dokud není ukončen server. Každý požadavek má tyto parametry:
Ve stejném okamžiku mohou současně platit požadavky na logování stejné situace, stejného uživatele a stejného objektu do různých logů. Zadáte-li proto požadavek na logování nové situace nebo nového uživatele nebo nového objektu nebo do nového logu, neovlivní se tím dříve zadané požadavky.
Požadavky na logování lze zobrazit, zadat, upravit nebo zrušit ručně na stránce Trasování okna Monitor. Seznam platných požadavků na logování také vrací systémový dotaz _iv_pending_log_reqs. Požadavky na logování lze z programu zadávat a rušit voláním standardní procedury _sqp_trace. Požadavky smí zadávat pouze Provozní správce databáze (požadavky na trasování dat pouze Bezpečnostní správce) - viz Administrování SQL serveru.
Situace, jejich výskyt lze logovat, se při volání funkce _sqp_trace označují identifikátory uvedenými v prvním sloupci. V druhém sloupci je písmeno, které se pro danou situaci objeví v logu. Ve čtvrtém sloupci jsou číselné hodnoty konstanty, které vrací systémový dotaz _iv_pending_log_reqs. Situace jsou rozděleny do tří tříd:
Globální situace týkající se provozu serveru:
| Identifikátor | Popis | Číslo | |
| TRACE_SERVER_FAILURE | F | Globální selhání serveru, včetně síťování, včetně dalších důležitých informací a varování. Mělo by být vždy zapnuto, ale tyto situace by neměly nastávat. | 2 |
| TRACE_NETWORK_GLOBAL | N | Trasování síťové komunikace, obvykle velmi zatíží systém nepřetržitým zápisem do logu, proto používejte jen na krátkou dobu. | 4 |
| TRACE_START_STOP | A | Informace o spuštění a vypnutí serveru a o chybách, které znemožňují spuštění. Mělo by být stále zapnuto. | 16384 |
| TRACE_SERVER_INFO | B | Základní informace o činnosti serveru (např. vytvoření zálohy, odpojení nekomunikujícího uživatele) a informace vyžádané na konzoli serveru (např. výpis paměti). Mělo by být stále zapnuto. | 65536 |
| TRACE_BCK_OBJ_ERROR | O | Syntaktická chyba v objektu, s nimž server pracuje na pozadí - může jit o trigger, globální deklarace ve schématu, implicitní hodnotu sloupce nebo integritní omezení v návrhu tabulky. | 2097152 |
Pro tyto situace se nezadává jméno uživatele, pro kterého se mají logovat.
Situace týkající se akcí konkrétního klienta:
| TRACE_USER_ERROR | E | Uživatelská chyba. Mělo by být stále zapnuto, doporučen plný kontext pro zjištění co nejvíce informací o chybě. | 1 |
| TRACE_SQL | S | Provedení SQL příkazu (včetně předem připravených příkazů), text příkazu včetně hodnot dynamických parametrů a proměnných klienta lze zobrazit v kontextu, proto doporučujeme nastavit kontext na hodnotu 2 nebo 3. | 64 |
| TRACE_LOGIN | L | Připojení a odpojení klienta, login a logout uživatele, u síťových připojení informace o IP adrese. | 128 |
| TRACE_LOG_WRITE | W | Explicitní zápis do logu pomocí procedury Log_write. Mělo by být stále zapnuto. | 1024 |
| TRACE_CURSOR | P | Otevírání a zavírání kurzorů včetně textu příslušného SELECTu, pokud je možné jej zjistit. protože se kurzory otevírají neustále, může toto nastavení zpomalit práci a zvětšit objem logu. | 256 |
| TRACE_IMPL_ROLLBACK | V | Implicitní provedení operace rollback kvůli chybě. | 512 |
| TRACE_PROCEDURE_CALL | P | Trasování volání SQL procedur pomocí CALL. | 4194304 |
| TRACE_TRIGGER_EXEC | T | Spuštění triggeru. | 8388608 |
| TRACE_USER_WARNING | I | Uživatelské varování. | 16777216 |
| TRACE_LOCK_ERROR | G | Podrobnosti o chybě 136 (NOT_LOCKED, tj. "nelze umístit zámek na záznam nebo diskový blok kvůli jinému zámku"), platí pouze pro ty případy, kdy se čeká na uvolnění a přitom vyprší timeout; a o chybě 171 (DEADLOCK) | 67108864 |
| TRACE_WEB_REQUEST | H | URL s HTTP požadavkem zaslané SQL serveru z web XML rozhraní při zapnuté emulaci web serveru | 134217728 |
Pro tyto situace lze buď zadat jméno uživatele, pro něhož se logují, nebo lze uvést prázdné jméno, a pak se logují pro všechny uživatele.
Další situace se týkají manipulací s tabulkami. Logovat lze:
| TRACE_READ | r | Čtení hodnoty ze záznamu z tabulky | 131072 |
| TRACE_WRITE | w | Přepis hodnoty v záznamu v tabulce | 262144 |
| TRACE_INSERT | i | Vložení nového záznamu do tabulky | 524288 |
| TRACE_DELETE | d | Zrušení (smazání) záznamu v tabulce | 1048576 |
Typicky se pro tyto situace zadává konkrétní sledovaná tabulka. Není-li zadaná žádná, pak se sledují všechny tabulky s výjimkou systémových. Dále lze buď zadat jméno uživatele, pro něhož se situace logují, nebo lze uvést prázdné jméno, a pak se logují pro všechny uživatele.
Po spuštění serveru je zapnuto logování do základního logu globálních situací A, B, F, situace W pro všechny uživatele a dále se zachová stav logování situace E pro všechny uživatele podle nastavení provedeného při posledním běhu serveru.
Pro situace týkají se akcí vyvolávaných uživateli může být požadavek na logování:
Je-li zadán požadavek na logování svázaný s uživatelským jménem, pak se uplatní jak pro klienty, kteří jsou pod tímto jménem již přihlášení, tak i pro klienty, kteří se pod tímto jménem teprve přihlásí.
Všechny logy se průběžně zapisují do souborů. Tyto soubory si lze prohlížet z různých počítačů pomocí nástrojů pro sdílení souborů v síti. Všichni klienti mohou číst pouze základní log. Ostatní definované logy může číst jen provozní správce databáze.
Nejnovější záznamy základního logu jsou vidět také v okně serveru.
Klient může získat nejnovější záznamy z libovolného logu pomocí systémového informačního dotazu _iv_recent_log (klient, který není správcem, pouze z logu základního). Tyto záznamy se zobrazují v okně Monitor na stránce Základní log. Požadavky na logování může klient získat pomocí systémového informačního dotazu _iv_pending_log_reqs. Velikost dat z logu přístupných klientovi je omezena vlastnosti serveru TraceLogCacheSize
Zvláště informace o uživatelských chybách, je-li zapnut plný kontext, mohou být poměrně obsáhlé a na první dojem složité k porozumění. Vezměme si běžnou chybu Duplicita záznamů v indexu. V logu je tento zápis:
19.6. 11:24:49 E ANONYMOUS Duplicita klíčů v tabulce POMTAB2 (4700): již existuje záznam se stejným klíčem (40004) {172} [Key 1 : 2] [Table 16 (POMTAB2), index 0 (INDEX1)][Inserting to table 16, record 16000]
[Procedure TEST3_2] [Procedure TEST3_ENVELOPE] [SQL: CALL `TESTY`.`TEST3_ENVELOPE`(:<KOLIKRAT{2})]
Zápis nám říká toto: Do tabulky jménem POMTAB2 byl vložen záznam, který hodnotami unikátního klíče koliduje se záznamem číslo 4700. Tato chyba má číslo 172, v SQL tomu odpovídá sqlstate 40004. Unikátní klíč se skládá ze dvou částí, první část má hodnotu 1, druhá část hodnotu 2 (zápis [Key 1 : 2]) - hodnota klíče, která způsobila chybu. Tabulka POMTAB má číslo 16. Unikátní index má číslo 0 a jméno INDEX1. Chyba nastala při vkládání záznamu, který by měl, kdyby se INSERT dokončil, číslo 16000. Chyba nastala v proceduře jménem TEST3 volané z procedury jménem TEST3_ENVELOPE. Procedura TEST3_ENVELOPE byla volána s hodnotou vstupního parametru rovnou 2.
Při zpětném hledání problému v datech mějte na vědomí, že touto chybou došlo k odvolání transakce, v níž k chybě došlo, proto tedy v tabulce nenajdete určitě záznam s číslem 16000 a pokud i záznam s číslem 4700 byl vložen v téže transakci, tak ani ten.
Po vypnutí a opětovném zapnutí serveru se zachovají pouze požadavky na logování do základního logu serveru, bez vazby na jméno uživatele nebo jméno tabulky. Ostatní požadavky je třeba (mají-li se zachovat i přes vypnutí serveru) volat pomocí funkce _sqp_trace v systémovém triggeru _on_server_start.
| Práva a jejich subjekty | | Provoz a správa 602SQL serveru | Systémové triggery | |