Udgangspunktet var følgende;

SQL> set timing on
SQL> create table X as select * from Y;

Table created.

Elapsed: 00:03:09.60

SQL> select count(*) from Y;

COUNT(*)
----------
108411

Det er en ganske almindelig tabel, ingen underlige typer, på en kraftig maskine hvor 3 minutter er meget lang tid. På en meget mindre maskine med 4 CPUer tager det et par sekunder. Det var lidt kritisk for vores leverandør, så det første var at finde en workaround.

SQL> create table X parallel (degree 25) as select * Y;

Table created.

Elapsed: 00:00:28.20

Det hjalp jo lidt på det! Men det er somsagt en work around! Så vi trak en AWR rapport. Leverandøren vendte hurtigt tilbage og var meget urolig for rapporten, da den jo viste at der var forbrugt 97% på CPU i det tidsrum rapporten repræsenterede (1 time).

Statistic                                                                           Name Time (s) % of DB Time
sql execute elapsed time                                                  1,215.14      99.88
DB CPU                                                                                1,188.51      97.69
parse time elapsed                                                                  20.32       1.67
PL/SQL execution elapsed time                                              2.52       0.21
hard parse elapsed time                                                          2.02       0.17
PL/SQL compilation elapsed time                                          0.31       0.03
connection management call elapsed time                         0.11       0.01
failed parse elapsed time                                                        0.04       0.00
hard parse (sharing criteria) elapsed time                           0.01       0.00
repeated bind elapsed time                                                    0.01       0.00
DB time                                                                                1,216.63  
background elapsed time                                                    283.52  
background cpu time                                                             101.19

Det er dog helt forkert tolket, idet de 97 % faktisk viser at maskinen udfører SQL på baggrund af at brugere/applikation beder om at få lavet noget arbejde, så det er positive 97%. Kigger vi på db time ser vi den er 1,216 sekunder, svarende til ca. 20 minutter i den time, snapshottet repræsenterer. DB CPU er tallet uden waits, lige under 20 minutters CPU forbrug.

Tilbage til problemmet! Efter at have gennemløbet AWR rapporten, kunne man se der var en del aktivitet omkring Oracles recycle bin. Det burde jo ikke have inflydelse! men som test valgte jeg lige at følge den til dørs.

SQL> alter session set recyclebin=OFF;

SQL> create table X parallel (degree 25) as select * from Y;
create table X parallel (degree 25) as select * from Y
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P021
ORA-01652: unable to extend temp segment by 8 in tablespace CREWS

SQL> alter session set recyclebin=ON;

Ups! Ja den har jeg prøvet før! Det er fordi der ligger data i recycle bin. Løsningen er purge.

SQL> purge recyclebin;

Recyclebin purged.

Lad os lige for sjov, uden at sætte recyclebin=OFF og uden brug af parallel og med et nyt tabelnavn, se om det har nogen effekt på vores create.

SQL> create table XX as select * from Y;

Table created.

Elapsed: 00:00:00.62

Det må man sige, det havde!