Warning: Declaration of Suffusion_MM_Walker::start_el(&$output, $item, $depth, $args) should be compatible with Walker_Nav_Menu::start_el(&$output, $item, $depth = 0, $args = Array, $id = 0) in /DISK2/WWW/plsql.cz/www/wp-content/themes/suffusion/library/suffusion-walkers.php on line 0
May 252013
 

Při hledání jednoho objektu v all_objects jsem narazil na mnou neznámé view DBA_HIST_COLORED_SQL. Obarvené sql? Neznal jsem a vypadalo to dost zajímavě. Takže jsem otevřel dokumentaci, abych se s view blíže seznámil a dokumentace říká: View se váže na funkci AWR a možnost reportovat nejen TOP SQL, ale také ty, které si označíme (“obarvíme”) pomocí funkce DBMS_WORKLOAD_REPOSITORY.ADD_COLORED_SQL.

Zní docela fajn, AWR sbírá jen TOP SQL a tohle je možnost jak do AWR dostat SQL, které tam mít chceme, ale není v TOP.

Takže go, hébičky go, jdem to zkusit!

Nejprve nějaký dotaz, který bude jednoduchý, tak aby nebyl v TOP SQL a bylo na něm vidět obarvení:

select max(dummy) as from dual;

Pak zjistit jeho sql_id:

select * from v$sql s where s.sql_text like '%max(dummy)%'

Což je : ’1twnyk3cacmfw’. A přidat do sledovaných sql_id pro AWR report:

begin
dbms_workload_repository.add_colored_sql('1twnyk3cacmfw');
end;

A test:
AWR Report a obarvení sql

Tak to by bylo přidání mezi obarvená sql a nyní sebrat snapshot, spustit sql, sebrat snapshot a zjistit jestli je opravdu reportované.

declare
i int;
begin
i:=dbms_workload_repository.create_snapshot;
dbms_output.put_line('ID='||to_char(i));
end;

Spustit sql:

select max(dummy) as from dual;

A znovu snapshot

declare
i int;
begin
i:=dbms_workload_repository.create_snapshot;
dbms_output.put_line('ID='||to_char(i));
end;

A nyní ověření, že i sql, které není zcela určitě v TOP se objeví v AWR reportu:

select * from table(DBMS_WORKLOAD_REPOSITORY.AWR_SQL_REPORT_TEXT(
l_dbid=>848445615,
l_inst_num=>1,
l_bid=>893,
l_eid=>894,
l_sqlid=>'1twnyk3cacmfw'));

WORKLOAD REPOSITORY SQL Report

Snapshot Period Summary

DB Name         DB Id    Instance     Inst Num Startup Time    Release     RAC
------------ ----------- ------------ -------- --------------- ----------- ---
ORCL8          848445615 orcl8               1 24-Kvě-13 13:17 11.2.0.1.0  NO 

              Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:       893 25-Kvě-13 09:12:13        40       3.3
  End Snap:       894 25-Kvě-13 09:12:41        37       3.5
   Elapsed:                0.47 (mins)
   DB Time:                0.02 (mins)

SQL Summary                               DB/Inst: ORCL8/orcl8  Snaps: 893-894

                Elapsed
   SQL Id      Time (ms)
------------- ----------
1twnyk3cacmfw          0
Module: SQL Developer
select max(dummy) as from dual

          -------------------------------------------------------------       

SQL ID: 1twnyk3cacmfw                     DB/Inst: ORCL8/orcl8  Snaps: 893-894
-> 1st Capture and Last Capture Snap IDs
   refer to Snapshot IDs witin the snapshot range
-> select max(dummy) as from dual

    Plan Hash           Total Elapsed                 1st Capture   Last Capture
#   Value                    Time(ms)    Executions       Snap ID        Snap ID
--- ---------------- ---------------- ------------- ------------- --------------
1   2522405774                      0             1           894            894
          -------------------------------------------------------------       

Plan 1(PHV: 2522405774)
----------------------- 

Plan Statistics                           DB/Inst: ORCL8/orcl8  Snaps: 893-894
-> % Total DB Time is the Elapsed Time of the SQL statement divided
   into the Total Database Time multiplied by 100

Stat Name                                Statement   Per Execution % Snap
---------------------------------------- ---------- -------------- -------
Elapsed Time (ms)                                 0            0.4     0.0
CPU Time (ms)                                     0            0.0     0.0
Executions                                        1            N/A     N/A
Buffer Gets                                       3            3.0     0.1
Disk Reads                                        0            0.0     0.0
Parse Calls                                       1            1.0     0.4
Rows                                              1            1.0     N/A
User I/O Wait Time (ms)                           0            N/A     N/A
Cluster Wait Time (ms)                            0            N/A     N/A
Application Wait Time (ms)                        0            N/A     N/A
Concurrency Wait Time (ms)                        0            N/A     N/A
Invalidations                                     0            N/A     N/A
Version Count                                     1            N/A     N/A
Sharable Mem(KB)                                 14            N/A     N/A
          -------------------------------------------------------------       

Execution Plan
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |     2 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |     2 |            |          |
|   2 |   TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------

Takže pro případ, že je třeba reportovat sql v AWR, které jsou pro nás zajímavé, ale nejsou v TOP:
DBMS_WORKLOAD_REPOSITORY.ADD_COLORED_SQL,

 Posted by at 08:05
Apr 062013
 

Dnes po delší odmlce alespoň tip na jednu knihu Secrets of the Oracle Database. I když velice rád mám oficiální dokumentaci, kterou má Oracle jako jednu z nejlepších - navíc nyní vylepšovanou o videa s tutoriálama a nově i s příklady. Jediné, co trošku kazí dojem je, že když vyťukáte adresu, kde by člověk čekal dokumentaci k Oracle 12c, tak je tam nehezká hláška, že beta dokumentace není pro každého..

Ale zpět ke knize Secrets of the Oracle Database - kniha je z vydavatelství Apress, což je vydavatelství, které o Oracle (a nejen o něm) vydává odborné knihy, což je takový unikát o proti tisíci knih popisující stále dokola funkci SUM() a UNION ALL.. Apress jde jinou cestou a vydává knihy, které často napsali velikánové typu Lewis, či Kyte a typicky se celá kniha věnuje jen jednomu tématu a hodně do hloubky (CBO, Indexy apod. jsou samostatné knihy).

Secrets of the Oracle Database od Norberta Debese se věnuje tomu nejzajímavějšímu – nedokumentované, skryté a tajné funkcionality Oracle. Zkryté parametry, fixed X$ pohledy, utility typu ORADEBUG atd.

Secrets of the Oracle Database

Secrets of the Oracle Database

http://www.apress.com/9781430219521

ISBN13: 978-1-4302-1952-1
Stran: 450

 Posted by at 12:41
Feb 132013
 

Nedočkavě sleduji tak to tedy bude s releasem Oracle Database 12c a kdy to tedy můžeme čekat ;). Minulý týden byly na internetu zprávy, že už je to skoro na spadnutí. Náhodou jsem však našel knihu New Features Oracle Database 12c, která sice neni ještě vydaná, ale na stránce rampamt pressu je seznam témat a jedním z nich je i “New BBED commands“.

BBED je tool, na který jsem ještě neměl moc času, ale je to jedna z utilit se kterou se dá pekelně vyřádit! BBED jeinterní tool Oracle sloužící k editaci databázových bloků. BBED umožňuje editovat hodnoty, smazat řádky pomocí editace datového bloku, přepočítat mu checksum ale také i obnovit řádky, – Oracle funguje podobně jako operační systém a po smazání řádku je řádek fyzicky pouze označen jako smazaný a přežívá do fyzického přepisu (update/insert jiných řádků, truncate, rebuild, shrink table..).

BBED je interní tool Oracle, takže do Oracle 10g  byl chráněn heslem (profláknutým a hardcodovaným..), od Oracle 11g bohužel chybí některé knihovny nutné pro spuštění tohoto toolu a je nutné je nakopírovat z Oracle 10g a snad právě pro to mi zaujalo téma “New BBED commands“,  neb to vypadá, že ani v novém Oracle nepřijdeme o BBED a bude možnost ho použít i když nepracujeme v Oracle Supportu, nebo alespoň já ne ;)

A nyní link na užasný dokument o BBED a jeden z nejvíce sexy dokumentů o Oracle:
Disassembling The Oracle Data Block

A narozdíl od profláknuté hlášky “do not try this at home”, tady platí pravý opak – doma a pouze doma.

 Posted by at 02:54
Feb 072013
 

Jak moc důležité je komentovat kód ví asi každý z nás – stačí se za pár měsícu vrátit ke svému programu či scriptu a člověk neví, která bije, to je prostě fakt – takže soubor tipů pro Oracle, kde je možné vložit komentář a vecpat tam svůj informační text.

1) Komentář nad tabulkou
COMMENT ON TABLE my_table IS 'azorova tabulka';
Komentář nad tabulkou by tak nějak měl být samozřejmostí, že? Mimo komentáře je také vhodný název tabulky, viděl jsem několik standardů jak se v systémech pojmenovávaly tabulky a objekty a žádný z nich nebyl vysloveně špatný, důležité je především nějaký mít. Osobně preferuji mimo báječného jména také nějaký sufix či prefix, který mi navíc podá další informaci. Jakou? Viděl jsem systémy, kde se do prefixu dávala informace, že je to tabulka (T_ ,TBL_), kde se tam dávalo schéma (AZOR_), kde se dávala další dodatečná informace (_CX,_SX) atd.
Takže mimo komentáře a hezkého názvu tabulky doporučiji sufix/prefix, který podá nějakou další informaci – taková která je pro daný systém nejlepší (pokud používáte aliasy hodí se například i to schéma).

2) Komentář nad sloupcem
COMMENT ON COLUMN my_table.my_column IS 'primární klíč, výrobní číslo';
Podobně jako nad tabulkou může být komentář i nad sloupcem. A i zde si myslim, že do 30 znaků se mimo hezkého jména i vejde nějaká dodatečná informace, například prefix PK_, pokud se jedná o primární klíč či _FK. Alternativně se hodně používá změna pořadí – ID_TABLE je primární klíč, zatímco TABLE_ID je cizí klíč. A mimo informace o klíči si občas vecpe nikdo do názvu jestli to má constraint či nějakou další informaci (_X jako má Siebel custom sloupce)

3) Nastavení SESSION – module/action pomocí dbms_aplication_info.
Oracle nabízí (jednoduchý a krátký balík) package dbms_aplication_info, který umožňuje označit si session a nastavit jim modul/action. Použití je následující:

begin
dbms_application_info.set_module('STAHOVANI_DAT','cisteni_temporary_tabulek');
end;

Což nastaví hodnoty modul a action pro aktuální session, které jsou pak vidět například v$session:

select module,action,t.* from v$session t where user#=sys_context('USERENV', 'SESSION_USERID');

Session info setnuté pomocí dbms_aplication_info

Session info setnuté pomocí dbms_aplication_info

Co je nepříjemné je omezená délka – 48 znaků pro modul, 32 pro action. A co tam patří? Ideálně package či procka, která v dané session běží a pokud to jde, dávám tám i informaci o % dokončení.

4) Komentování kódu a PLSQLDOC
Popisovat celé PLSQL_DOC by asi nemělo smysl, takže pouze link: PLSQL_DOC s informací, že utilitka trošku zastarává a jsou novější náhrady (v SQL Developeru například), nicméně stále šikovná utilitka – z headu balíku to vygeneruje něco, co vypadá jako klasické JAVADOC.

5) Pojmenovní transakce
 a) stará verze
COMMIT COMMENT 'moje transakce, klidne rollbacknete';
b) nová verze
SET TRANSACTION NAME 'moje transakce';
To je asi featura, která nikdo z nás moc nepouživá. Bohužel. Tak alespoň na distribuovaných databází by to chtělo.

6) Sledování selectu s komentářem
Na internetu jsou často vidět “pojemenování” selectu pomocí komentáře za slovem select, aby se lépe identifikoval v pohledech:

select /* azoruv_select */ from all_tables where table_name like..

Což se přiznám moc nepouživám – hodně to nahrazuje dbms_aplication_info.

7) Propis do V$SESSION_LONGOPS
Package dbms_aplication_info má mimo set_module ještě jednu zajímavou funkci set_session_longops, která umožní založit záznam do V$SESSION_LONGOPS, příklad má Oracle přímo v dokumentaci k package DBMS_APLICATION_INFO.

Edit: Na základě komentáře ke článku (za který děkuji) jsem opravil slovo surfix na sufix - a někdo by to měl opravit i ve všech packages a veškeré dokumentaci, kterou jsem kdy udělal ;), protože to nebyl překlep, ale celý život to píšu špatně, wow.

 Posted by at 19:09
Sep 202012
 

Otázka na začátek – může databáze vracet jiné výsledky pro stejný select ale pro jeho jiné exekuční plány? Neměla by.., pokud je select správně napsaný, pokud se nemluví o bugu Oracle a pokud … a pokud? Pokud vím, tak v dokumentaci je jedna vyjímka, kde Oracle přímo píše, že dva stejné selecty s různým exekučním plánem mohou “legálně” vracet jiné hodnoty a to v případě poškozeného datového bloku v tabulce a nastaveném skipu “corrupted blocks” (DBMS_REAPIR) a dva selecty – jeden proti tabulce full scanem a druhý proti  indexu (bez “corrupted blocks”).

Dneska jsem se rozhodl Oracle trošku potrápit – a přinutit ho k nehezkému chování, tím že mu poruším odkazy v indexu a Oracle bude vracet jiné řádky přes index a jiné přes full scan. Takže go hébičky go!

Upozornění: Updatovat systémové tabulky pod SYSem “není doporučeno” a může (a dělá to) poškozovat databázi.

1) Nejprve založení nějaké testovací tabulky
create table invalid_index_test_tbl tablespace USERS as select rownum id_key, rownum my_value from dual connect by level<20000;

2) Nyní založení indexu
create index inx_index_unusable_text on invalid_index_test_tbl(id_key);

3) Alterování indexu do UNUSABLE stavu
alter index inx_index_unusable_text unusable;

4) Odmazání řádek
Je třeba odmazat nějaké řádky, abychom získali prostor na shirnk space a rozhodili pozici řádků vůči rowid uloženým v indexu:
delete from invalid_index_test_tbl where my_value<8000 or (my_value>12000 and my_value<15000)
commit;

5) Enable row movement a Shrink space
Povolíme fyzický přesun řádků (enable row movement) a přesuneme řádky na promazané místo, tzn “setřesení tabulky” (shrink space)
alter table invalid_index_test_tbl enable row movement;
alter table invalid_index_test_tbl shrink space;

6) Hledání co vlastně updatovat
Nejzajímavější část je najít, co je třeba vlastně updatovat, nejjednodušší je podívat se na definici ALL_INDEXES, ve které je vidět:
decode(bitand(i.property, 2), 2,
decode(i.type#, 9, decode(bitand(i.flags, 8),
8, 'INPROGRS', 'VALID'), 'N/A'),
decode(bitand(i.flags, 1), 1, 'UNUSABLE',
decode(bitand(i.flags, 8), 8, 'INRPOGRS',
'VALID')))

Podle definice ALL_INDEXES je to update do tabulky sys.ind$ a bitově sloupec FALGS, potenciálně sloupec property. Co třeba je vědět je číslo objektu, například přes  select * from sys.obj$ where name like upper(‘%inx_index_unusable_text%‘) . Moje číslo je 21988 a updatovat flags budu na 2050 (zjištěno z testovacího indexu,nemá cenu se počítat s bity)

7) Update sys.ind$
update sys.ind$  set flags=2050 where obj# in (21988);
commit;

8) Index je “validní” v systémových tabulkách Oracle, takže test:
select /*+ index(t) */ * from invalid_index_test_tbl t where id_key=2
ORA-01502: index ‘SYS.INX_INDEX_UNUSABLE_TEXT’ or partition of such index is in unusable state
01502. 00000 – “index ‘%s.%s’ or partition of such index is in unusable state”
*Cause: An attempt has been made to access an index or index partition
that has been marked unusable by a direct load or by a DDL
operation
*Action: DROP the specified index, or REBUILD the specified index, or
REBUILD the unusable index partition

Proč? Updatovat systémové tabulky pod SYSem by se nemělo, Oracle při tom dělá spoustu věcí (hlavně validacích, že..), které uživatel neudělá nebo udělat ani nemůže. Jednou z nich bude patrně invalidace stavu objektu v paměti, ale to naštětí lze řešit:

9) Čištění..
ALTER SYSTEM FLUSH SHARED_POOL;
Z mých zkušeností plyne, že je třeba flushnout shared_pool téměř vždy, když si hraji pod SYSem..

10) Výsledný pohled na selecty – jeden přes znásilněný index, druhý fullscannem:

Full vs Index

Full vs Index

Super, ne? Stejné selecty – jiný hint a jiný výsledek.

Vada na kráse? Tím jak byla shrinkuta tabulka jsme posunuly řádky a tabulka byla zmenšena – tedy index pro vyšší hodnoty (za předpokladu, že Oracle insertnul data z selectu za sebou – neni zaručeno) odkazuje někam do pryč.. tedy:

11) Fail select:

select /*+ index(t) */ * from invalid_index_test_tbl t where id_key=15000;

S výsledkem (což je ta lepší varianta)
ORA-08103: object no longer exists
08103. 00000 – “object no longer exists”
*Cause: The object has been deleted by another user since the operation
began, or a prior incomplete recovery restored the database to
a point in time during the deletion of the object.
*Action: Delete the object if this is the result of an incomplete
recovery.

A

select /*+ index(t) */ * from invalid_index_test_tbl t where id_key=10800;

Což je ta horší varianta:
(ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
00600. 00000 – “internal error code, arguments: [%s], [%s], [%s], [%s], [%s], [%s], [%s], [%s]“
*Cause: This is the generic internal error number for Oracle program
exceptions. This indicates that a process has encountered an
exceptional condition.
*Action: Report as a bug – the first argument is the internal error number)

Vylepšení? Tabulku znovu roztáhnout – nainsertovat řádky a zase je smazat (???? pokud pujdou do stejné části datového souboru, jako byly předtím). Trefit to přesně na záznam tak tu máte úžasné chování ;) Další možností je updatovat segmenty indexu a udělat si vlastní “polotrucate” indexu a zkrátit ho.

Vždycky lítaj třísky, když si člověk hraje, nicméně vypadá to, že pak stačí rebuildnout index:

 alter index inx_index_unusable_text rebuild;

 K čemu je to dobré? K ničemu. Na stranu druhou – to dokazuje, že shrink space funguje a dokonce i jak se tam sypou řádky – o kolik je posunut index vůči řádkům…¨

—————-

A neodpustím si jednu věc ze života mimo Oracle pro dnešek:

Zlato ve tmě modře nesvítí, což je dost nepříjemný fyzikální constrain :-/

 Posted by at 23:37
Sep 162012
 

Asi není novinkou, že je venku Enteprise Manager Clound Control 12c. Dnes již dokonce pod releasem R2. Podobně již je venku Weblogic 12c. Kde c znamená “cloud” a není to nic jiného než nutnost použití slova, které aktuálně frčí, podobně jako tomu bylo u verze 9i, kde I mělo znamenat Internet..

Co zbývá? Oracle Database 12c. Sehnat nějaké informace o nové verzi Oracle je stále nemožné, mimo NDA, pod kterým jsou všichni v beta programu (a nikdo z mých “blízkých” to není). To ještě komplikuje nařízení regulátora (USA) o ohlašování releasu, pod kterým je Oracle jako firma taková. Nicméně – co Oracle může a o čem už mluvil Larry Ellison, že by Oracle Database 12c mohla přijít v prosinci tohoto roku (i to tak vychází podle jejich release politiky) či na začátku roku 2013.

Což pro nás technicky znamená neplnit ledničky na Vánoce cukrovím, ale Red Bully neb nás na Vánoce možná čekají noční instalce a čtení manuálů.

Bohužel vzhledem k silnému NDA nevím, s čím Oracle v nové verzi DB přijde, mimo toho slova “cloud” , protože nějaký “clound” tam bude muset být, což bude bohužel spíše nová hračka pro DBA, ne pro nás programátory. Zatim jsem zaslechl pouze o značném vylepšení ovlivňovat optimalizátor. Logicky bych pak čekal nějakou podporu pro Weblogic, něco pro Fusion, vylepšení TimesTen (tam čekám hodně)  a pokračování snižování nákladů na administraci a maintenence databáze  – tedy vylepšení či nové advisory a auto tunning tasky.

 Posted by at 00:16
Sep 022012
 

Nedávno jsem dospěl k názoru, že Oracle dostává v selectu “téměř” seřazená data, přeste jeho chování a délka operace SORT trvá pořád stejně. Dává to smysl, na stranu druhou pokud dostatu data, která jsou “téměř” seřazená, dokáži vymyslet algoritmus jež je seřadí rychleji, možná né řádově, ale určitě rychleji (pochopitelně o to hůř se bude chovat nad náhodnými daty). Takže jsem začal googlit a manuálovat, jestli nádhodou není možné nějak řazení vylepšit a jaký vlastně algoritmus Oracle interně použivá. Možnost vlastního SORT algoritmu patrně neexistuje, Oracle Data Cartrige nabízí všechny možné šikovné věcičky, ale tohle prostě ne. Oracle použivá od 10g nový alogoritmus řazení a jedná se o Quick Sort (pivot je vybrán jedním průchodem přes data) říznutý Most Significant Digit Radix Sortem, rychlost řazení tedy závisí i na délce řazených prvků, konkrétně O(k·n).

http://en.wikipedia.org/wiki/Radix_sort#Most_significant_digit_radix_sorts

Quick Sort:

Quick Sort

 Posted by at 23:51