Vzhledem k tomu že jsem si vzal na starosti natáčení a následné zpracování videa z pravidelných setkání CZJUGu, musel jsem se po podívat na základní zpracování videa pod Linuxem - kdysi dávno jsem toto prováděl ve Windows v Adobe Premiere, a hledal jsem jsem něco obdobně komfortního a flexibilního. Předpokládám že nejsem sám kdo podobný problém řeší, takže si dovoluji v krátkosti popsat "své řešení" založené na nástrojích ffmpeg a kdenlive.
Instalace Oracle 11g (R2) na nepodporované distribuci (ty jsou aktuálně tři - Oracle Enterprise Linux, Red Hat a SuSe) může být poněkud problém - a to zejména pokud je distribuce "progresivní" tj. pokud obsahuje velmi nové verze různých nástrojů (kompilátor, knihovny) a pokud není založena na RPM balíčcích. A oboje platí pro mé oblíbené Gentoo, takže se podívejme na jaké nástrahy lze při instalaci narazit (a jak je překonat).
Pokud plánujete využít partitioning k rozdělení neustále rostoucí tabulky na menší části, budete muset vyřešit problém vytváření nových partitions. Není úplně žádoucí aby tato činnost byla (alespoň na produkčním systému) řešena čistě manuálně - jako daleko spolehlivější se jeví automatizace. Podívejme se na několik možných způsobů jak automatickou správu partitions řešit ...
V PostgreSQL existují dva koncepčně zcela odlišné způsoby jak řešit partitioning - přes rules a přes triggery. Jedním z důvodů využití partitioningu je často i výkon, takže se podívejme jak se tyto dvě cesty liší právě ohledně výkonu.
Na rozdíl od předchozích čistě technických článků si tentokrát dovolím krátké zamyšlení nad hinty v Oracle, ke kterým mám poněkud nejednoznačný vztah. Občas sice ve slabší chvilce připustím že se hodí, ale většinou je celkem upřímně nenávidím ...
Partitioning lze použít jako elegantní řešení široké škály problémů - distribuci tabulky na více disků (pokud z nějakých důvodů nechcete použít RAID pole), efektivní mazání archivních dat (bez DELETE), atd. Automaticky ho lze realizovat pomocí triggerů nebo pravidel. Podívejme se na puzzler související s partitioningem realizovaným pomocí RULE.
Pokud jste se v někdy trochu seriózněji zabývali laděním výkonu v některé z novějších verzí Oracle, možná jste se setkali s legendárním statspackem (viz. také Oracle Statspack Survival Guide), či s jeho následovníkem Automatic Workload Repository (AWR) jehož princip spočívá ve vytváření "snapshotů" důležitých interních statistik (počet dotazů, transakcí, čtení z disku, z cache, ...) a následné analýze rozdílů mezi provedenými snapshoty. Málo se ale ví že pro PostgreSQL existuje nástroj pgstatspack, který už svým názvem na Statspack odkazuje - je založen na stejném principu (analýza rozdílů mezi snapshoty), a i když je pochopitelně jednodušší může být stejně neocenitelným pomocníkem při ladění výkonu.
Přibližně před rokem jsem si pořídil netbook Eee PC 1000H od firmy Asus - hned od začátku jsem na něm provozoval své oblíbené Gentoo a KDE 3.5, i když to občas nebylo bez komplikací. Ale vzhledem k tomu že jsem "notorický vrtač" a "ignorant zpráv z portage" dostal se můj netbook do stavu kdy nebylo jiné cesty než kompletní reinstalace - a to rovnou na KDE 4.3.
Předem upozorňuji že se nejedná o instalační návod - konec konců k tomu máme výborný Gentoo Handbook. Spíše se jedná o užitečné a zajímavé informace specifické právě pro 1000H (a případné podobné netbooky), tj. například konfiguraci jádra, use flagy, místa kde jsem měl problémy apod.
Čas od času je potřeba během vývoje otestovat reakci aplikací na "úmrtí" databázového serveru. V PostgreSQL mailing listu se na toto téma odehrála poměrně zajímavá diskuse, ve které se objevilo několik zajímavých přístupů (od velmi elegantních až po brutální). Podívejme se tedy na jednotlivé způsoby zabíjení PostgreSQL ...
Říká se že "Cesta do pekel je dlážděna dobrými úmysly," a platí to i pro SQL dotazy. Mnoho problémů je způsobeno vývojáři kteří se snaží o optimalizaci a snížení zatížení databáze, mnohdy ale bohužel bez potřebných znalostí o vnitřním fungování.
