Primi test con 11g

mercoledì 3 dicembre 2008 alle 03:49 | Pubblicato su 11g, Installation and Configuration | 7 commenti
Tag: , , ,

Stamattina nel mio RSS feed reader (si dice così?) è comparso un nuovo post di Christian Antognini. Oggi sono arrivato in ufficio molto presto per un’attività; terminata l’attività presto e per fortuna senza problemi ho dato un’occhiata. Il post segnala la disponibilità sul sito del materiale della presentazione sulle nuove caratteristiche dell’ottimizzatore Oracle nella versione 11g. Dando un’occhiata veloce al documento la mia attenzione è stata catturata dalla prima slide di pagina 4, intitolata “Index Support for Linguistic LIKE”. Dall’esempio riportato sembra che Oracle abbia colmato quella che molti lamentavano come lacuna, ovvero la possibilità di fare ricerche case-insensitive indicizzate. Ad ogni versione Oracle aggiunge qualcosa, e con questo nuova aggiunta forse soddisfa le richieste di molti utenti.

Lunedì ho preparato una nuova virtual machine on Oracle Enterprise Linux 4U5 a 64 bit (ne ho clonata una su cui faccio dei test per 10.2.0.4) e vi ho installato proprio Oracle 11.0.1.6 a 64 bit. Siccome un nostro cliente ha fatto una migrazione su 11g (seppur su AIX, sempre 64 bit) ed ha avuto dei problemi e facendo delle ricerche pare che tali problemi si verifichino anche su altre piattaforme a 64 bit, ho deciso di provare a martellare questa istanza di test con swingbench per vedere se riuscivo a riprodurre l’errore. Se dovessi riuscirci il passo successivo sarebbe l’applicazione della patch set 11.1.0.7 per vedere se tale patch set risolve i problemi. Ho lasciato tutto ieri e stanotte girare swinghbench ma senza errori.

Stamattina allora ho pensato di testatare la ricerca case-insensitive con il like e indicizzata come dimostrato da Antognini.  Per farlo ho pensato di utilizzare un “test case” mio e ho pensato di farlo usando una tabella dello schema SOE creato proprio da swinghbench. La tabella candidata ideale mi è sembrata la CUSTOMERS, così fatta:

SQL> desc customers
Name                                      Null?    Type
—————————————– ——– —————————-
CUSTOMER_ID                               NOT NULL NUMBER(12)
CUST_FIRST_NAME                           NOT NULL VARCHAR2(30)
CUST_LAST_NAME                            NOT NULL VARCHAR2(30)
NLS_LANGUAGE                                       VARCHAR2(3)
NLS_TERRITORY                                      VARCHAR2(30)
CREDIT_LIMIT                                       NUMBER(9,2)
CUST_EMAIL                                         VARCHAR2(100)
ACCOUNT_MGR_ID                                     NUMBER(6)

Come campo ho pensato di utilizzare il campo CUST_LAST_NAME, inserendo un record con il mio cognome. Purtroppo però, pur avendo la tabella quasi due milioni di record, i valori distinti del campo CUST_LAST_NAME sono 180, il che probabilmente impediva all’ottimizzatore di usare l’indice. Infatti usando un HINT il piano d’esecuzione mostrava un INDEX RANGE SCAN come affermato nella presentazione di Christian Antognini. Non contento allora ho cercato un modo veloce per “sparpagliare” i dati, ovvero fare un update che aumentasse la distribuzione dei valori del campo cust_last_time così da indurre l’ottimizzatore ad utilizzare l’indice di spontanea volontà come fa Antognini nei “test case” che allega alla sua presentazione. Ora, non sono sicuro che l’update che ho lanciato faccia quello che volevo, però il risultato non è stato per nulla buono:

SQL> /
update customers set cust_last_name=nvl((select object_name from all_objects where object_id=customer_id and rownum=1 and object_name is not null),’CIRIPACCHIO’)
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 11275
Session ID: 100 Serial number: 12575

Quello che ho travato in coda all’alert è:

Errors in file /opt/oracle/diag/rdbms/test11/test11/trace/test11_ora_11275.trc  (incident=2641):
ORA-00600: internal error code, arguments: [kcbgcur_9], [0], [4194851], [1], [4294967250], [2], [], []
Incident details in: /opt/oracle/diag/rdbms/test11/test11/incident/incdir_2641/test11_ora_11275_i2641.trc
Wed Dec 03 10:39:18 2008
Trace dumping is performing id=[cdmp_20081203103918]
Wed Dec 03 10:39:25 2008
Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x619B851, qmxiManifestVArray()+3991]
Errors in file /opt/oracle/diag/rdbms/test11/test11/trace/test11_ora_11275.trc  (incident=2642):
ORA-07445: exception encountered: core dump [qmxiManifestVArray()+3991] [SIGSEGV] [ADDR:0x0] [PC:0x619B851] [SI_KERNEL(general_protection)] []
Incident details in: /opt/oracle/diag/rdbms/test11/test11/incident/incdir_2642/test11_ora_11275_i2642.trc
Wed Dec 03 10:39:27 2008
Sweep Incident[2641]: completed
Wed Dec 03 10:39:35 2008
Trace dumping is performing id=[cdmp_20081203103935]
Wed Dec 03 10:40:27 2008
Sweep Incident[2642]: completed

Non mi è piaciuto molto. L’errore non è lo stesso subito dal nostro cliente, anche li si vedevano dei ORA-07445, ma accompagnati da ORA-03137.

Riguardo ORA-600 [kcbgcur_9] tutto ciò che ho trovato è stato la nota metalink 114058.1 che però fa riferimento ad argomenti diversi e a versioni precedenti alla 11g.

Sul ORA-7445 invece ho trovato la nota 46028.1 che sembra pertinente. Essa fa riferimento ad un errore di corruzione della SGA che ricollega all’ORA-600 che secondo la nota precedente pare essere un problema di gestione della buffer cache. La nota 46028.1cita il bug numero 5686407.8 che fa riferimento a un ORA-600 [171xx] che io non ho ma nel trace c’è un riferimento a XDB citato nella descrizione del Bug. Poi nei workaround del bug c’è:

(2) Be sure there is sufficient memory in the shared pol.

Io in effetti, a causa di scarsa disponibilità di risorse ho circa 312 MB di SGA_MAX_SIZE e SGA_TARGET (modalità ASMM, non AMM con MEMORY_TARGET).

Ora ho rilanciato l’update per vedere cosa accade.

7 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ciao Cristian, interessante:
    a primo sguardo anche a me sembra che non ci siano dubbi sul fatto che il problema interessi il layer della cache in quanto kcb dell’ora-600 indentifica proprio quel layer;
    per il layer interessato invece dall’ora-07445, qmx esso sembrerebbe identificare l’estensione per l’xml (il riferimento quindi ad XDB lo trovo pertinente)

  2. Probabilmente dirò una banalità.
    Mi chiedevo se anziché utilizzare l’operatore LIKE, non conviene utilizzare le espressioni regolari.
    Forse LIKE è più immediato, ma con REG_EXP si ricade nello stesso problema?

  3. Ciao Andrea,
    non credo si tratti affatto di una banalità. Le espressioni regolari sono una cosa un po’ più complessa (e che molti informatici, fra cui io, conoscono poco). Su come funziona l’indicizzazione in questo caso sono perplesso, non lo so.

  4. si potrebbe provare con REGEXP_LIKE

  5. […] Recenti Alessandro Deledda su Primi test con 11gCristian Cudizio su Primi test con 11gAndrea su Primi test con 11gAlessandro Deledda su […]

  6. […] I miei test interni con Oracle 11g su Linux 64 bit di cui ho già scritto in due post precedenti (questo e questo) sono proseguiti a singhiozzo. Qualche giorno fa sono riuscito a installare la patchset […]

  7. […] funzionalità su Oracle 11g, per questo motivo ho pensato di accendere la macchina virtuale che ho gia utilizzato tempo fa per fare un po’ di test su questa release di Oracle che in azienda ancora non utiliziamo. […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: