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 2. rész

Folytatom az Oracle 11g újdonságainak felsorolásával és rövid bemutatásával a sorozatot:

Partitioning

Ezentúl az alábbi összetett particionálási lehetőségeink vannak:

  • Range-range
  • Range-hash
  • Range-list
  • List-range
  • List-hash
  • List-list

További hasznos opció a Reference Partitioning melynek segítségével egy „B” táblán úgy hozhatunk létre partíciókat, hogy a partíciók a vele külső kulcson kapcsolt „A” tábla oszlopai szerinti particionálásnak megegyezően készüljön el. Így a B tábla partíciói olyan oszlopokon alapulnak amik az A táblában vannak.

Az Intervallum particionálással végre az Oracle saját maga képes létrehozni a range particionáláskor az egyes partíciókat. Nekünk csak definiálni kell az partíció intervallumok méretét, és a rendszer automatikusan létrehozza a partíciókat, szükség szerint az adatok insertálása közben. Az új partícióneveket a rendszer generálja ezért nem tudunk rá könnyen hivatkozni, viszont ezentúl lehetőségünk van a partícióra dátummal hivatkozni : SQL> select * from my_table partition for (to_date('2010.05.07','yyyy.mm.dd'));

A system partitioning abban az esetben jó, ha nem tudunk logikus particionálási módot választani, ekkor az alkalmazásnak  a beszúrás közben kell meghatározni, hogy melyik partícióba kerüljön az új rekord, és ugyanígy, lekérdezésnél és törlésnél is érdemes meghatározni, különben a teljes táblát végignézi az Oracle.

Az Oracle 10g-ben korábban már lehetőségünk volt táblatereket transzportálni, amely az egyik leggyorsabb módja az adatmozgatásnak. Most már ha egy partíció külön táblatérben van akkor az is elmozgatható külön. Az átmozgatott partíció létrehozza a táblát az új helyen ha ott nem létezik.

Virtuális oszlopokon alapján is lehet partíciót létrehozni, tehát olyan adatok alapján amik nem is léteznek fizikailag.

Ezentúl a particionáláshoz is tartozik tanácsadó (partition advisor).

Schema Management

Sok újdonság van ebben a pontban is: DDL műveletek is elláthatunk már wait opcióval. Tehát amennyiben egy tranzakció exclusive lock-ot alkalmaz egy táblán, akkor nem sikerülhetnek  a ddl műveletek, és egyes esetekben ha sok tranzakció pörög, akkor akár órákig próbálkozhatna a rendszergazda a DDL műveletét végrehajtani (pl.:új oszlop hozzáadása).  E helyett beállítható, hogy a DDL művelet pl.:10 másodpercet próbálkozzon a lefutással. Ez akár session vagy adatbázis  szinten is beállítható.

Default értékekkel feltölthetünk egy újonnan létrehozott not null oszlopot úgy, hogy az adatbázis nem tölti fel fizikailag az oszlopot, hanem az adatszótárba jegyzi meg, hogy minek kéne lennie az oszlopban. Ez a funkció elég hasznos egy több millió soros tábla esetében: idő és energia spórolás.

Ehhez kapcsolódik az az újítás, hogy virtuális oszlopokat hozhatunk létre. A tábla definíciójában definiálhatjuk az oszlop tartalmát, mely akár komplex logikai kifejezés is lehet. Ezekben a virtuális oszlopokba nem lehet adatot beszúrni, csak lekérdezni.

Elrejthetők az egyes indexek az optimalizáló elől, „láthatatlanná” lehet az indexet tenni. Ilyenkor az optimalizáló nem használja, csak abban az esetben ha külön nem adjuk meg neki hintben. E mellett az indexet továbbra is karban tartja az Oracle.

A 11g újdonsága az az opció is, hogy read only módba kapcsolhatók egyes táblák is. Ezelőtt csak különböző nehézségek árán lehetett ezt elérni. (triggerek, VPD policy).

Pontosabb objektumok közti függőség kezelést valósít meg a 11g. Így hogyha egy olyan oszlopa módosul egy táblának amitől közvetlen nem függ a táblán lévő trigger, vagy egy eljárás, akkor ezek az objektumok nem lesznek invalid állapotúak, mint korábban.

IPv6 támogatás is beépült a rendszerbe, most már IPv6 címekkel is hivatkozhatunk az adatbázisra.

Lehetőségünk van most már segment nélküli tábla létrehozásra. Ez azért hasznos, mert nem feltétlen kerül a táblába létrehozásakor adat, így feleslegesen foglalhatja a helyet (szegmens + egy extent).

Index szegmensek esetében a nem használt (unusable) állapotban levő szegmensek által foglalt helyet az Oracle felszabadítja. Ez akkor hasznos ha régi index partíciók helyét akarjuk felszabadítani. Ez a művelet használhatatlanná tenné a táblának ezt a partícióját is 10g-ben, viszont ezentúl ez nem jelent majd problémát, az Oracle 11g végigolvassa majd az adott partíciót, a hibajelzés helyett.

Data Warehousing and OLAP

Az olap kockákat illetve dimenziókat melyeket az adatbázisban tárolunk, egy új fv (cube_table) segítségével, most már egyszerűen sql segítségével elérhetjük.

select * from table(cube_table('<schema>.<dimension>;<hierarchy>'))

Ezt az sql-t elmenthetjük nézetbe, és így a klienseknek nem kell ismerniük ezt a szintaktikát sem. Továbbá a kockák materializált nézetként is működhetnek, és query rewrite-ot is megvalósítanak.

A query rewrite is tovább fejlődött, most már az átíráshoz selectnek nem kell teljesen megegyeznie formailag a materializált nézetben eltárolt selecttel.

Új meta tábla jött létre az adatbázisban, DBA_MVIEW_DETAIL_PARTITION, mely megmondja, hogy egy adott materializált nézethez tartozó tábla adott partíciójában az adatok frissek-e vagy sem.

Egy új tool (java kliens) segíti ezentúl az analitikus objektumok létrehozását, kezelését, ez az Analytic Workspace Manager.

PL/SQL: Efficient Coding

Új fajta trigger jelent meg a 11g-ben: compound trigger. Melynek segítségével egy monolitikus PL SQL kódrészletben írhatunk meg before, before row, after row, after triggert. Ez azért előnyös, mert így a triggerek osztozhat a változókon.

Az ugyanazon a táblán kialakított azonos típusú  triggerek közt ezentúl definiálhatunk sorrendiséget. Meghatározhatjuk, hogy melyik trigger melyiktől függjön (follows <trigger név>). A 10g-ben ez nem volt meghatározható.

A continue paranccsal gazdagodott a ciklus kezelés. Melynek segítségével a következő iterációra léphetünk vagy egymásba-ágyazott ciklusok esetén ki is léphetünk egy külső ciklusba címkék használatával.

Ezentúl a szekvenciák következő értékét ki lehet írni változóba, külön select into használata nélkül is, egyszerű plsql értékadással.

PLSQL warning (PLW) üzeneteket kaphatunk ha beállítjuk,

alter session set plsql_warnings = 'enable:all' Így hasznos figyelmeztetéseket kaphatunk, hanyag módon megírt programunk fordítása közben. pl.: ha lenyeljük az exception-okat:

exception when OTHERS

then

null;

end;

A triggereket ezentúl kikapcsolhatjuk (disable). Így ha fordítjuk őket, akkor információt kaphatunk a fordítás sikerességéről/hibákról, anélkül, hogy a rendszert zavarnánk hibás triggerekkel.

Amennyiben select-ből hívunk függvényeket a 11g-ben kiírhatjuk a paraméter neveket, a „=>” szintaktikával. Lehetőségünk van Native Dynamic SQL-t és REF CURSOR-t egymásba konvertálni.

Típus függőségek esetén ha szülő típust módosítunk, akkor ezt a 10g nem engedi, amíg a van rá típus hivatkozás (gyerek). A 11g-ben lehetőségünk van kényszeríteni a módosítást a FORCE klauzulával.

A cikk forrása az Oracle hivatalos oldala.

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

Oracle 11g new features 3. rész

Security

A biztonság terén is sok újítás készült:

Lehetőségünk van egy új nézet (DBA_USERS_WITH_DEFPWD) segítségével ellenőrizni, hogy a felhasználók default jelszavakat használnak-e.

Végre kis-nagybetű érzékenyek lettek a jelszavak. Viszont továbbra is használható a régi érzéketlen mód, arra az esetre ha gondunk akadna, valamelyik alkalmazással.

A jelszavak minőségének kikényszerítését megvalósító függvény (verify_fnction_11g) új, fejlettebb logikával rendelkezik. Ezt a fv-t a utlpwdmg.sql script generálja.

Az auditálás az alábbi objektumokra alapértelmezetten be van állítva:

  • ALTER SYSTEM
  • SYSTEM AUDIT
  • CREATE SESSION
  • CREATE USER
  • ALTER USER
  • DROP USER
  • ROLE
  • CREATE ANY TABLE
  • ALTER ANY TABLE
  • DROP ANY TABLE
  • CREATE PUBLIC DATABASE LINK
  • GRANT ANY ROLE
  • ALTER DATABASE
  • CREATE ANY PROCEDURE
  • ALTER ANY PROCEDURE
  • DROP ANY PROCEDURE
  • ALTER PROFILE
  • DROP PROFILE
  • GRANT ANY PRIVILEGE
  • CREATE ANY LIBRARY
  • EXEMPT ACCESS POLICY
  • GRANT ANY OBJECT PRIVILEGE
  • CREATE ANY JOB
  • CREATE EXTERNAL JOB

Ez az auditálás a DB-be a SYSTEM táblatér AUD$ táblájába történik, így figyelni kell, hogy nehogy megteljen ez a táblatér, mert ez komoly problémákhoz vezet. A felsorolt műveletek, egy átlagos adatbázisban azonban nem okoznak nagy terhelést, illetve sok adat generálást.

A 10g-ben bevezetett transparent tablespace encryption-t is tovább fejlesztették. Most már tudja alkalmazni az Oracle az indexeket a kódolt adatokra. Ugyanis a memóriában a kikódolás után tudja alkalmazni az index scan-t. A kódolás nem jelent nagy extra terhelést a porcesszornak. A kódoló kulcsokat az Oracle wallet-ben tárolja, melyet külön kulccsal lehet kinyitni.

A Data Pump Dump fájlok esetében is alkalmazható a titkosítás, így az archívumaink is biztonságban lehetnek.

Acces Controll List-ekkel korlátozhatjuk az adatbázisból kimenő kapcsolatokat, melyeket az UTL_TCP, UTL_HTTP és UTL_SMTP csomaggal hozhatnak létre a fejlesztők. Meghatározhatjuk a cél szervert, illetve a  portot ahova a kimenő csatlakozás irányul.

(dbms_network_acl_admin.create_acl, dbms_network_acl_admin.add_privilege, dbms_network_acl_admin.assign_acl)

Adat maszkolást már az adatok exportálása közben megvalósíthatjuk az új Data Pump funkcióval: remap_data=[<SchemaName>.]<TableName>.<ColumnName>:[<SchemaName>.]<PackageName>.<FunctionName>

Így egy keverő plsql fv-t alkalmazhatunk a kiexportálandó oszlopra.

Ezentúl az Enterprise Manager-ből intézhetjük a security beállításokat, és nem kell az Oracle Security Managert használnunk.

Az audit adatok törlésére eddig csak úgy volt lehetőségünk, hogy ha leállítjuk az auditálást és törlünk. A 11g-ben immár rendelkezésre áll a dbms_audit_mgmt csomag melynek eljárásaival ezt menet közben is megtehetjük. (init_cleanup, clean_audit_trail, create_purge_job, set_audit_trail_property)

Új funkció az is, hogy az audit adatokat átmozgathatjuk, az előbb említett csomag segítségével (set_audit_trail_location).

Több RAC instance-on keresztül is használhatók már a globális alkalmazás context-ek. Ezekben változó értékeket tárolhatunk és több session-on/alkalmazáson/instance-on keresztül biztonságosan érhetjük el. (create context, dbms_session.set_context, select sys_context).

A listener jelszó beállítási funkciója többé nem használatos, felesleges funkcióvá vállt.

Új privilégiumot hoztak létre: execute -directory objektumokra. Melynek segítségével az adatbázison kívüli alkalmazások futtatásának jogát állíthatjuk. Ez azért is fontos, mert a 11g-ben például megtehetjük azt, hogy egy becsatolt külső tábla selectálása előtt elindítsunk külső programot mely pl.: kitömöríti az adatokat, mielőtt az adatbázis olvassa őket. Ezt a külső program futtatást, külön auditálhatjuk is természetesen.

Új audit funkció továbbá az audit all statements is, mely lekorlátozza az auditált parancsok körét a felhasználó által direkt hívott/kiadott parancsokra, és nem jeleníti meg az indirekt parancsokat. Például ha a felhasználó egy funkciót hívott, akkor nincs az audit trailben részletezve a függvény által hívott további parancsok listája. Így könnyebben kezelhető audit log keletkezik.

Beállítható a saját session teljes auditja is (audit all in session current) mely csak az adott session-t figyeli, és nem az összest. Így könnyebb megkeresni egy hibát, mely egy hívási lánc mélyén történt, és nincs róla egyébb információnk, csupán annyi hogy valahol a programban hibás tábla hivatkozás volt.

A Transparent Data Encryption (TDE) terén is finomítottak a 11g R2-ben. Csak 1 mester kulcsot kell használnunk, mind oszlop, mind táblatér szintű kódolás esetén (unified master encryption key). Amúgy a táblatér szintű TDE a 11g R1-ben jelent meg. A mester kulcs ahogy korábban említettem, wallet-ben van tárolva amit külön ki kell nyitni. Ezt RAC esetén, nem kell minden instance-on külön megtennünk. Habár a táblateret/táblákat kódoló kulcsot nem de a mester kulcsot - mely a többi kulcsot kódolja - megváltoztathatjuk.

A by session audit, mely idáig csak egy audit rekordot generált egy táblahozzáférés/session esetén most már ugyanúgy viselkedik mint a by access audit. Annyi rekordot generál ahányszor az adott táblához hozzáfértek.

A cikk forrása az Oracle hivatalos oldala.

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

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