PostgreSQL - Příspěvky [cs]

Soubor:Logo.png

2009-01-21T23:16:02Z

127.0.0.1: načítá „Soubor:Logo.png“: (recovered file, missing upload log entry)

Importing image file

Šablona:Xxx

2006-02-19T10:36:33Z

127.0.0.1:

Trotl testuje sablony {{{pokus}}} a taky neco jinyho
<table border = 1>
<tr><td>{{{a|}}}
<tr><td>{{{b}}}
</table>
aaa<div class{{{param1}}}="hiddenStructure">param1: {{{param1}}}</div>bbb
{| border=1
|-
<div class{{{x1}}}="hiddenStructure">x1={{{x1}}}</div>
<div class{{{x2}}}="hiddenStructure">x2={{{x2}}}</div>
<div class{{{x3}}}="hiddenStructure">x3={{{x3}}}</div>
|-
|}

4.01 Jak získat pouze první řádek dotazu? Náhodný řádek?

2005-12-26T18:58:20Z

127.0.0.1:

Pokud potřebujete pouze několik řádků a pokud víte kolik, použijte
SELECT LIMIT. Pokud bude možné použít index shodující se s ORDER BY,
je možné, že se nebude provádět celý dotaz. Pokud neznáte počet záznamů,
použijte kurzor a příkaz FETCH.

Pro výběr náhodného řádku použijte příkaz ve tvaru:
<pre>
SELECT col
FROM tab
ORDER BY random()
LIMIT 1;
</pre>
[[Category:4. Provozní dotazy]]

Write Ahead Logging

2005-12-07T16:18:29Z

127.0.0.1:

Jedná se o obvyklý mechanismus zajištění transakcí, tj. datové soubory (tabulky a indexy) jsou modifikovány až poté, co byl pořízen záznam do logu. Díky tomu, že lze obsah databáze zrestaurovat z transakčního logu, není nutné vynucovat zápis na disk (fsync) datových souborů modifikovaných v transakci ve chvíli potvrzení transakce. Stačí fsync logu. Přínosem je:
* vyšší výkon - redukce fsynců, navíc možnost sdílení fsynců v konkurenčním prostředí, tj. důsledkem potvrzení (COMMIT) více transakcí je jeden požadavek na fsync logu,
* skutečná konzistence datových stránek, před zavedením WAL mohlo dojít k poškození indexů případně tabulek bez možnosti rekonstrukce. Nyní se po restartu provádí automatická obnova datových stránek na základě jejich obsahu v logu,
* možnost online zálohování a obnovy k námi určenému okamžiku (PITR). Systém udržuje pouze několik posledních bloků (souborů) transakčního logu. Pokud je ale zálohujeme (provedeme jejich kopii), můžeme následně z těchto kopii rekonstruovat databázi (obdoba obnovy po pádu). Prvotní záloha nemusí být absolutně konzistentní (postačí kopie souborů svazku provedená za chodu). Přehrávání logu (při obnově) můžeme zastavit v libovolném okamžiku před koncem logu (každá operace zapsaná v logu obsahuje časovou značku), např. těsně před okamžik, kdy byly odstraněny důležité tabulky nebo data (PITR).

Multi Version Concurent Control

2005-12-07T16:10:07Z

127.0.0.1:

Úkolem databázového systému je zajištění konzistence dat při současném zpracování požadavků více uživatelů. Snahou je vzájemně izolovat jednotlivé transakce - chceme, aby nepotvrzené změny dat způsobené ostatními transakcemi byly v transakci neviditelné. Nevýhodou řešení založeném na zamykání (tabulek, stránek, řádků) jsou možné vykonnostní problémy. Řešením je MVCC architektura, kdy namísto zamknutí modifikovaného řádku (ať operací Upadate nebo Delete) se provede kopie řádku - vytvoří se nová verze.

Nepotvrzené verze a přepsané verze se odstraňují až ve chvíli, kdy nejsou viditelné z žádné transakce. Neodstraňují se automaticky, je třeba spouštět příkaz VACUUM. Kromě odstranění nedostupných záznamů má příkaz VACUUM na starosti taká aktualizaci statistik používaných plánovačem dotazů, a ochranu před přetečením identifikačních čísel transakcí (stabilní záznamy obdrží id 2, tj. FrozenXID).

Kategorie:Projekty

2005-11-15T08:37:00Z

127.0.0.1:

Dokumenty projektu respektují následující [[Strukturování projektové dokumentace |strukturu dokumentů]].