http://itanalyst.hu/modules/mod_image_show_gk4/cache/ita_head_1gk-is-90.pnglink
http://itanalyst.hu/modules/mod_image_show_gk4/cache/ita_head_2gk-is-90.pnglink
http://itanalyst.hu/modules/mod_image_show_gk4/cache/ita_head_3gk-is-90.pnglink
http://itanalyst.hu/modules/mod_image_show_gk4/cache/ita_head_4gk-is-90.pnglink
«
»
Ön itt van: Home Programfejlesztés Támogatás Oracle 11g new features 4. rész

Oracle 11g new features 4. rész

Memory manegement

Az memória kezelése ismét könnyebben adminisztrálhatóvá vált. Az adatbázis memória foglalása több process, és memória terület beállításától függ pl.: PMON, SMON, System Global Area (SGA), Program Global Area (PGA). A 10g-ben még csak az SGA_TARGET-paraméterben határozhattuk meg azt a célszámot amit  az SGA tart és ezen belül automatán hangolja az alegységeit (pl.:cache, shared pool). Viszont a PGA-t és db_cache_keep_size-ot továbbra is manuálisan kellett beállítani. 11g-ben a teljes memória használatra adhatunk egy limitet (MEMORY_TARGET) amelyen belül minden SGA/PGA/pool/cache-eket automatikusan hangol a rendszer. Ezen túl meghatározhatunk egyes elemeknek minimum értékeket is (sga_target, pga_aggregate_target). Az automatikus hangolás eredményét megtekinthetjük az adatbázis konzolról és nézetekben is (v$memory_dynamic_components, v$memory_resize_ops)

Az adatbázis által adott figyelmeztetéseket finomíthatjuk az adaptive treshold-ok beállításával. Lehetőségünk nyílt a 11g-ben adaptív figyelmeztetési szinteket definiálni, melyek követik az adatbázis jellegzetes terhelését. A terhelés információk az AWR-ben gyűlnek (Advanced Workload Repository). A figyelmeztetésekre százalékokat, és előfordulási gyakoriságokat, és fix értékeket is beállíthatunk.

Statistics

Pending Statistics - Késleltethetjük a statisztikák megjelenését az optimalizáló számára. Ami tesztelési okokból lehet előnyös. Lehet, hogy nem szeretnénk, ha reggel arra ébrednénk, hogy egyből az esti statisztikák legyártása után, az egész adatbázis, nem várt módon viselkedik, és kellemetlen perceket okoz a felhasználóknak. (Persze a statisztika gyűjtéssel általában javulnak az SQL tervek.) Tehát először a statisztikák publikálásának felfüggesztését állítjuk be az adott táblára(dbms_stats.set_table_prefs pname   => 'PUBLISH', pvalue  => 'FALSE' ) utána statisztikát gyűjtünk (dbms_stats.gather_table_stats), a user_tables nézetben ellenőrizhetjük az élő statisztika időpontját. (Ez nem változik a függő statisztika gyűjtésének időpontjára, hanem a korábbi időpontot mutatja.) Tesztelhetjük az függő statisztikát (alter session set optimizer_use_pending_statistics = true;) törölhetjük ha nem tetszik az eredmény (dbms_stats.delete_pending_stats), illetve élesíthetjük ha minden jó (dbms_stats.publish_pending_stats). Amennyiben hibáznánk, és elengednénk egy hibás tervet, akkor visszatérhetünk egy korábbi állapotra a 11g alapértelmezetten 31-nap statisztika történelmet tart meg, ezt a dba_tab_stats_history táblában nézhetjük illetve a dbms_stats.restore_table_stats eljárás segítségével visszaállhatunk.

Extended Statistics Function-Based Statistics - A kibővített ill. funkció alapú statisztikák használatával egyedi tippeket adhatunk az SQL optimizer-nek (dbms_stats.gather_table_stats( method_opt =>) ). Ami nagyon hasznos lehet, ha tudjuk, hogy a lekérdezéseink úgy is az adott fv-t használják, és ezzel megváltoztatják a lekérdezett adatok statisztikai eloszlását. Az így kialakult eloszlást nem ismerheti eredendően az optimalizáló, ezért nem is biztos, hogy optimális végrehajtási-tervet készít. Az optimalizálónak speciális kiegészítésként adott és eltárolt tippeket lekérdezhetjük a dba_stat_extensions táblából, illetve törölhetjük (dbms_stats.drop_extended_stats).

Multi column statistics - Régóta várt funkció mellyel oszlopok közötti korrelációkra világíthatunk rá az optimalizálónak. Például ha két oszlopra külön szűrünk és önmagában mindkét szűrés sok elemet ad -> full table scann az optimális, viszont ha együtt alkalmazzuk a szűréseket, akkor kis számosságú eredményünk lesz -> index range scan lehet optimális végrehajtási terv. Alapvetően az optimalizátor külön értelmezi az oszlopok számosságát, viszont ha külön kialakítunk csoportokat (dbms_stats.create_extended_stats, vagy dbms_stats.gather_table_stats method_opt ) az oszlopok közt, akkor közös számosságok alapján is tud most már dönteni.

Online Patching

A 11g-ben lehetőségünk van egyes patch-eket online telepíteni. Nem kell az adatbázist leállítani a memóriában lévő kód frissül.

További lehetőség az is, hogy a feature patch-ek jelennek meg, tehát például a particionálást javító patch-et nem kell installálni abban az adatbázisban ahol az nincs használva. Viszont a biztonsági patch-eket mindenképp ajánlott telepíteni.

Pivot és Unpivot

Ha még nem programoztad le a mátrix transzponálást (pivotálás) akkor 11g-ben már nem is kell. Hiszen bevezették új klauzulaként az SQL nyelvbe. A szintaktikába nem mennék bele a cikk keretében, viszont érdekes lehetőség, hogy az eredményeket xml-ben is megkaphatjuk (soronként clob-ba csomagolva), és ebben az esetben nem kell felsorolnunk az oszlopait a készített táblázatnak. A visszaforgatásra is lehetőségünk van az unpivot klauzulával.

A cikk forrása az Oracle hivatalos oldala.

http://www.oracle.com/technetwork/articles/sql/index-099021.html