Con la versione 10g Oracle ha introdotto la cosiddetta “Recovery Area”, che io solitamente uso per gli Archive Log.  Essendo la gestione degli Archive Log una cosa importante, nel mio script di backup è inclusa una parte che controlla l’occupazione di spazio degli archive log ed eventualmente ne fa il backup o la cancellazione onde prevenire blocchi del database. Per fare tale controllo il mio script utilizza una query sulla vista V$FLASH_RECOVERY_AREA_USAGE, in particolare la query è:

select round(percent_space_used) from v$flash_recovery_area_usage where file_type='ARCHIVELOG';

Oggi scopro che tale vista non è più documentata in 11gR2, è sostituita da V$RECOVERY_AREA_USAGE, la vista con il vecchio nome però esiste ancora e infatti il mio script scritto per 10gR2 apparentemente funzionava anche su 11gR2. Dico apparentemente perché qualcuno in Oracle ha avuto la bella idea di fare un cambiamento ben più importante, cambiando la descrizione riportata nel campo FILE_TYPE per gli archive log da “ARCHIVELOG” a “ARCHIVED LOG”.  Nulla di che se non il fatto che la query utilizzata nella mia vecchia versione dello script on funzionava più, ragion per cui ho inaugurato la versione 11.2 del mio script di gestione dei backup su piattaforma linux.

Altra cosa bizzarra e che forse spiega la rimozione dalla documentazione ufficiale di tale errore è che nei nostri database il tipo LONG cui si riferisce il testo del messaggio di errore non è mai esistito.

Un indizio che mi aiutò all’inizio a capire da cosa potesse derivare questo errore è il fatto che l’errore abbia fatto le prime comparse dopo che siamo passati sui nostri database al character set UTF-8 (mentre prima si usava ISO-8859 o equivalente). Potrei dedicare un intero post solo a descrivere le mie peripezie a cercare di fare test con la gestione di caratteri non ASCII con il character set UTF-8 ma per ora soprassiedo.

Oltre alle difficoltà a fare dei test con l’UTF-8, per la cui gestione da windows ho ancora delle difficoltà che ho aggirato usando putty e collegandomi su macchine linux, sono stato ingannato dal comportamento di funzioni come RPAD che fa cose come questa:

SVILUPPO42@perseo10 > select length(rpad('a',4500,'b')) from dual;

LENGTH(RPAD('A',4500,'B'))
--------------------------
4000

Comportamento del tutto lecito e anche logico, ritornando tale funzione un tipo dato VARCHAR2 che ha come limite appunto 4000 (byte), ma non essendo espressamente specificato nella documentazione non davo per scontato. Poi sulle funzioni SQL in Oracle occorre sempre fare attenzione, se sono usate in SQL valgono delle regole, in PL/SQL le cose sono leggermente diverse (e un varchar2 in PL/SQL può arrivare a 32767 (byte)

Riassumendo riporto le prove che ho fatto:

SQL> create table test_char (a varchar2(1300 char));

Table created.

Primo tentativo di aggirare il limite di RPAD

SQL> insert into test_char values (rpad('a',4000,'b')||'test');
insert into test_char values (rpad('a',4000,'b')||'test')
*
ERROR at line 1:
ORA-01489: result of string concatenation is too long

Al che ho deciso di provare con bind variables ma ho incontrato un’altra anomalia:

SQL*Plus: Release 11.2.0.2.0 Production on Fri Oct 28 14:44:27 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> var v_test varchar2(4000 char);
SP2-0676: Bind variable length cannot exceed 1000 characters

Il che è dovuto, come ho scoperto in seguito, semplicemente al fatto che avevo settato (erroneamente) la variabile d’ambiente

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

Quindi ho deciso di passare a un test con PL/SQL:

SQL> declare
a varchar2(5000 char);
begin
a :=rpad('a',2000,'a');
insert into test_char values (a);
end;
/  2    3    4    5    6    7
declare
*
ERROR at line 1:
ORA-12899: value too large for column "TEST"."TEST_CHAR"."A" (actual: 2000,
maximum: 1300)
ORA-06512: at line 5

Dove si ottiene l’errore che mi aspetto. In realtà questo test funziona anche con una insert diretta con RPAD direttamente via SQL, ma il caso interessante è questo:

SQL> declare
a varchar2(5000 char);
begin
a :=rpad('a',4000,'a')||'test';
insert into test_char values (a);
end;
/  2    3    4    5    6    7
declare
*
ERROR at line 1:
ORA-01461: can bind a LONG value only for insert into a LONG column
ORA-06512: at line 5

Che è l’errore che cercavo. Ho cercato di analizzare il trace generato attivando l’evento 10046 ma non ci ho trovato nulla di interessante.  L’errore si verifica anche da Java con driver JDBC, parrebbe che essendo una  stringa con lunghezz superiore ai 4000 caratteri la variabile venga convertita in tipo long e da ciò deriva l’errore, è una supposizione che faccio.

Il caso concreto che mi sono trovato ad affrontare è stato fare funzionare Oracle BI versione 10g per dei test. Questa versione di Oracle BI è certificata al massimo su Windows 2003, peccato al primo tentativo di accesso alla console di amministrazione, gestita dall’application server OC4J installato su una macchina win2003 io abbia avuto un errore per l’impossibilità da parte di Java di allocare memoria. Gli script di avvio di OC4J per default contengono le opzioni

-XX:MaxPermSize=128m -Xmx512m

Ho provato allora a modificare tali impostazioni impostando

-XX:MaxPermSize=128m -Xmx1024m

Ma questo è risultato provocare un errore gia in avvio di OC4J.

Una veloce ricerca sul Web mi ha portato a questo interessante post che da un metodo per verificare quanta memoria al massimo è in grado di allocare Java. Ho potuto fare così test interessanti su varie macchine, verificando che effettivamente su altre macchine win2003 il comando di test fallisce:

C:\Documents and Settings\utente>java -mx768m -XX:MaxPermSize=128m -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
C:\Documents and Settings\utente>java -mx768m -XX:MaxPermSize=64m -version
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

In questo caso specifico la macchina ha 2GB di RAM fisica, ma dal task manager risulta usato circa 1,6 GB su 4GB di memoria virtuale.

Nei miei studi giovanili la gestione della memoria virtuale nei sistemi operativi è stata presente, fra l’altro a quei tempi simili dimensioni per la RAM erano fantascienza, però io non ho trovato la spiegazione del fatto per cui in tali condizioni il sistema operativo non è in grado di allocare meno di 1 GB di memoria.

Vincendo la mia pigrizia e la mia repulsione ho fatto ulteriori ricerche ed ho trovato questi riferimenti nella documentazione di MS, “virtual address space” e “Confronto tra le architetture della memoria a 32 a 64 bit“.

Pare che con il flag /3GB nel boot.ini di una macchina con 2,5 GB di RAM le cose migliorino, infatti sono arrivato ad allocare quasi 1,5 GB di heap per la JVM.

L’unica macchina Linux a 32 bit che sono riuscito a trovare è una macchina virtuale su cui ho ottenuto questi risultati:

[oracle@vboxm1 ~]$ java -mx2650m -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode)
[oracle@vboxm1 ~]$ java -mx2750m -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
[oracle@vboxm1 ~]$ uname -a
Linux vboxm1 2.6.18-194.0.0.0.4.el5 #1 SMP Thu Apr 8 18:20:19 EDT 2010 i686 i686 i386 GNU/Linux
[oracle@vboxm1 ~]$ free
             total       used       free     shared    buffers     cached
Mem:        909120     820564      88556          0      27572     656228
-/+ buffers/cache:     136764     772356
Swap:      1735012          0    1735012

Chiaramente le macchine a 64 bit (anche se non reali come  gli Xeon) simili problemi non si presentano, neanche su win2008 a 64 bit.

A completamento del discorso devo dire che in passato ho avuto anche problemi con oracle database server 10gR2 su windows che in sistemi particolarmente carichi avevo frequenti errori ORA-04030

Con la versione vecchia del programma di utilità di Oracle per esportare su file binari schemi di database, chiamata Export, era possibile usare unità sequenziali (come i nastri) o le “named pipes” dei sistemi operativi *NIX. In particolare mi è capitato per motivi di spazio di sfruttare queste ultime per fare la compressione al volo del dump, con questa tecnica:

mknod /u01/backup/exp/export_pipe p
nohup /usr/bin/gzip < /u01/backup/exp/export_pipe > /u01/backup/exp/dbaceh.dmp.gz 2>
/u01/backup/logs/gzip.log &
$ORACLE_HOME/bin/exp user/senha@dbaceh file=/u01/backup/exp/export_pipe buffer=40000000
log=/u01/backup/logs/dbaceh.log full=y >>$ARQLOG 2>>$ARQLOG

(fonte: nota MOS 463336.1)

Con Oracle Data Pump come certificato dalla nota MOS 276521.1 non è più possibile perché le ottimizzazioni che lo rendono effettivamente più veloce dei vecchi exp/imp comprendono il fatto di non accedere in modo sequenziale al file.

In 11.2.0.2 le vecchie utility exp/imp sono ancora presenti e documentate, quindi un’alternativa (che però non mi piace) è continuare a utilizzare quelle, seppur pare non sia supportata se non per casi limitati e descritti nella documentazione.

Tracciando il piano di esecuzione di una query sulla V$OPEN_CURSOR si verifica parte di quanto dice Alessandro:

--------------------
SQL_ID  3xyw5tppy1w8t, child number 0
-------------------------------------
select * from v$open_cursor where sid=1

Plan hash value: 2659856713

-----------------------------------------------------------------
| Id  | Operation        | Name    | Rows  | Bytes | Cost (%CPU)|
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |         |       |       |     1 (100)|
|*  1 |  FIXED TABLE FULL| X$KGLLK |     1 |   121 |     0   (0)|
-----------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - filter(("KGLLKSNM"=1 AND "KGLHDNSP"=0 AND
"INST_ID"=USERENV('INSTANCE') AND "KGLHDPAR"<>"KGLLKHDL"))

la vista alla base della V$OPEN_CURSOR è la X$KGLLK dove in effetti si possono trovare ancora più informazioni, il problema è decifrarle.

Ricordo che io sono partito dalla necessità di individuare il testo di un statement il cui cursore in qualche ciclo non veniva chiuso provocando l’errore ORA-1000. Il numero di cursori aperti dato dal conteggio sulle statistiche è quello da prendere a riferimento e che se raggiunge il limite imposto dal parametro OPEN_CURSORS provoca l’errore ORA-1000. Il numero di record in  V$OPEN_CURSOR per una data sessione è sempre maggiore al numero di cursori realmente aperti che possono portare all’errore  ORA-1000. Dal punto di vista dell’occupazione di memoria e delle prestazioni presumo sia effettivamente vero che si possono considerare i cursori riportati nella V$OPEN_CURSOR come aperti.

Ho fatto il seguente test, ho aperto una sessione con un utente, da un’altra ho interrogato la V$OPEN_CURSOR con la seguente query:

select saddr,sid,count(*) from v$open_cursor where sid=151 group by saddr,sid;

il cui risultato era:

SADDR    SID                    COUNT(*)
-------- ---------------------- ----------------------
2DF4C87C 151                    2
2DF6569C 151                    3
2DF4A0AC 151                    1
2DF53FEC 151                    5
2DF389FC 151                    2
2DF4016C 151                    18
2DF6BA24 151                    9
2DF3C5B4 151                    2
2DF3128C 151                    5
2DF2D6D4 151                    6

Il database è poco usato, suppongo che quelli siano cursori di sessioni aperte e chiuse in precedenza, che hanno avuto lo stesso SID ma SADDR diverso. Ho provato a chiudere la connessione e riaprirla subito dopo (da sql*plus) e questa a ripreso lo stesso SADDR (ma diverso SERIAL#). Essendo tutti statement su viste di sistema, ad esempio:

select privilege# from sysauth$ where (grantee#=:1 or grante

ho ipotizzato che siano legati a chiamate ricorsive però qui siamo un po’ sull’esoterico

Settando per la sessione di test il parametro SESSION_CACHED_CURSORS a 0 in effetti non si trovano poi nella V$OPEN_CURSOR record per la coppia SID,SADDR

Il thread di AskTom segnalato da Alessandro mi pare quello che ho visto anche io ieri ma come quasi tutti questi thread faccio fatica a leggere fino in fondo.

Ieri ho trovato anche questo post di Dion Cho che confesso di non aver compreso a fondo, che però da anche un suggerimento per approfindire l’analisi: fare un dump dello stato del processo con l’istruzione:

alter session set events 'immediate trace name processstate level 10';

Mi è venuta in mente all’uopo la vista di sistema V$OPEN_CURSOR che secondo la documentazione della versione 10gR2 mostra i cursori che ogni sessione ha “correntemente” (currently) analizzato e aperto (opened and parsed). Per evitare che alcune mie traduzioni possano fuorviare dove ho dubbi riporto anche la dicitura originale del manuale. In realtà credo che tale definizione sia fuorviante, perché tale vista mostra i cursori attualmente in cache, senza dare informazione alcuna sul fatto che siano aperti o meno.

Faccio un piccolo passo indietro, cos’è un cursore? Anni fa mi sono scritto una sorta di guida oracle personalizzata e in questa guida mi ricordavo di aver annotato anche queste informazioni, prelevate dal manuale “Concepts” secondo il quale sono collegamenti (handle) a aree di memoria private della sessione, le “private SQL Area” che a seconda della configurazione si trovano nella Shared Pool (server condivisi o shared server) o nella PGA (server dedicati o dedicated server). Il numero massimo di cursori che una sessione può aprire è limitato dall’impostazione del parametro OPEN_CURSORS che ha come valore di default 50 secondo la documentazione ma che io sui miei database (10.2.0.3 e 10.2.0.4) trovo impostati a 300 in quanto pare sia uno dei valore così impostati dal Database Configuration Assistant che solitamente uso per creare i database.

Interrogando la vista V$OPEN_CURSOR per un determinato SID si ottengono normalmente diversi record e ciò mi ha lasciato decisamente spiazzato. Uno dei motivi pare essere l’impostazione del parametro SESSION_CACHED_CURSORS che secondo la documentazione  come default il valore ’0′ ma che sui miei database ha come default il valore 20. Ciò significa che sulla V$OPEN_CURSOR non vengono visualizzati solo i cursori aperti per ogni sessione, ma anche quelli in cache. L’unica informazione certa che si può avere sui cursori aperti per una sessione, anche secondo la nota del supporto  oracle 743605.1 (occorre un accesso al supporto oracle per visualizzare il link) che conferma quanto ho scritto sopra, è il numero di cursori aperti (salvo bachi), ottenibile con la query:

select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic#  and s.sid=a.sid
and b.name = 'opened cursors current'
and a.sid=<SID>;

Anche in una discussione su Asktom mi sembra si affermasse ciò riportanto la stessa query.

Mi rimangono alcune perplessità, interrogando la V$OPEN_CURSOR per una singola sessione posso trovare un numero di record superiore al valore del parametro SESSION_CACHED_CURSOR, alcuni legati allo stesso SID ma a diverso SADDR, colonna i cui significato non è ben chiaro, anche se sospetto sia legata a chiamate ricorsive.

Statspack è un package PL/SQL e un insieme di tabelle che servono per raccogliere statistiche sul sistem Oracle. Statspac richiede una tablespace con almeno 100 MB libero, deve essere installato sul database da monitorare da un utente con privilegi SYSDABA. Lo script per l’installazione è $ORACLE_HOME/rdbms/admin/spcreate.sql.  Lo script creerà un utente PERFSTAT.

Statspack permette di fare delle fotografie del sistema (SNAPSHOT) ovvero sia di raccogliere  le statistiche che Oracle normalmente mantiene in in dato istante temporale. Per generare uno snapshot delle statistiche bisogna eseguire come utente PERFSTAT la procedura STATSPACK.SNAP(). Ci possono essere vari livelli di statistiche da 1 a 10, da meno dettagliate a più dettagliate (il default è 5). I parametri di default si cambiano in modo permanente con la procedura STATSPACK.MODIFY_STATSPACK_PARAMETER().

Per generare un report che consiste nel riassunto delle statistiche raccolte tra due snapshot si può usare lo script $ORACLE_HOME/rdbms/admin/spreport.sql. Lo script $ORACLE_HOME/rdbms/admin/sppurge.sql si può usare per eliminare vecchi snapshot.

Per disintallare statspack si usa lo script $ORACLE_HOME/rdbms/admin/spdrop.sql, da lanciare sempre con un utenza con privilegi SYSDBA.

Oggi per la prima volta da quando lo uso ho trovato un problema su statspack, su una installazione 10.2.0.3. Il problema si manifestava con l’errore

ORA-00001: unique constraint (PERFSTAT.STATS$MUTEX_SLEEP_PK) violated

al tentativo di creare uno snapshot.

Per fortuna qui ho subito trovato la descrizione e la soluzione al problema con il riferimento alla nota 382993.1 del supporto Oracle.

Approfitto anche per ricordare che Kerry Osborne tempo fa aveva parlato di statspack su 11g e di un paio di problemini che su questa versione sono sti introdotti.

Sono molto acido perché confesso di avere sempre  più in antipatia MS, i suoi prodotti e l’ostinazione e pervicacia di quanti responsabili di sistemi informatici si buttano sui prodotti di questa grande azienda che fa buoni prodotti, quando altre aziende li hanno fatti 10 anni prima.

Leggendo quell’articolo mi sembrava di avere un déjà vu , di leggere un articolo su XEN o VMWare o Oracle VM o si Amazon AWS di tre anni fa, quando sappiamo che nell’informatica tre anni sono molti.  Solo pochi giorni fa Alex Gorbachev ha pubblicato su pythian questo post  in cui spiega come accendere in pochi minuti una macchina virtuale sui servizi di amazon (per i nuovi iscritti per un anno gratis), ho provato io stesso, investendo ben 6 centesimi di dollaro che mi verranno addebitati sulla mia Postepay a fine mese per provare un paio d’ore una macchina con Oracle Enterprise Linux e il nuovo Oracle database Express edition 11gR2 beta.

C’è l’ho con MS perché l’utente medio è affascinato dalle finestrelle e dagli effetti grafici, più che non dalla sostanza, pochi giorni fa Eddie Awad ha condiviso su google buzz un interessante articolo in cui si cerca di spiegare con un esempio concreto perché l’interfaccia a linea di comando (CLI) è superiore alle interfaccie grafiche (GUI).

Ho foderato questo post di link (a mio modesto parere tutti interessanti) perché non ho la pretesa di essere autorevole, ma penso che la miglior informazione sia dare riferimenti a fonti ed esempi concreti e magari attuali.

Più per tradizione e per adeguarci alla richiesta di molti clienti anche noi applichiamo tutt’ora la classica suddivisione di tablespace per i dati e per gli indici, pur non vedendo alcun motivo scientifico per fare ciò. Quando però si fanno export/import di tipo tradizionale, e si vuole mantenere tale suddivisione ma con nomi di tablespace diversi la cosa non è immediata. Con datapump è stato introdotto il comodissimo parametro REMAP_TABLESPACES, ma sul vecchio import non c’è una soluzione diretta, se non ci sono tablespace con lo stesso nome del database di origine, gli oggetti vengono creati sul tablespace di default dello schema su cui si importano gli oggetti. Le tecniche per ovviare a ciò sono diverse, ma ieri ne ho collaudata una che non avevo mai provato e che però mi è sembrata molto comoda, la riassumo brevemente:

1) impostazione per l’utente/schema della tablespace di default quella dei dati (tabelle)

2) importazione del dump senza indici, ovvero con parametro INDEXES=no

3) impostazione per l’utente/schema della tablespace di default quella degli indici

4) importazione del dump senza dati, quindi con parametro ROWS=no IGNORE=yes INDEXES=yes

il parametro IGNORE=yes fa si che l’import non termini con errore perché trova gia le tabelle.

In passato una delle tecniche che ho utilizzato è stata quella di utilizzare il parametro INDEXFILE per generare su file i DDL degli indici, modificare il file opportunamente e lanciare da sqlplus la creazione degli indici, oppure importare tutto e poi spostare gli indici ma quest’ultimo è sicuramente il metodo più scomodo perché richiede di allocare più spazio nella tablespace dei dati e un po’ di manovre per generare lo script di spostamento per tutti gli indici.