27 agosto 2007

OpenSuSE 10.2/64 e driver nVidia

Posto qui questo avviso perché dovrebbe interessare maggiormente chi come me fa prove su Oracle e Linux a 64 bit.
La nVidia evidentemente legge il mio blog :-) e ha deciso di rilasciare i driver nForce (i chipset nVidia) versione 1.23 anche per OpenSuSE 10.2.
Unico piccolo difetto è che la versione "build" del kernel di rilascio è quella precedente all'ultimo aggiornamento ufficiale (2.6.18.8-0.5-default), ma l'installazione dell'rpm e il caricamento del modulo vanno a buon fine. Bisogna comunque eseguire mkinitrd per ricreare il ramdisk di avvio, visto che comunque il modulo sata_nv viene richiesto all'avvio del kernel. Fatevi prima una copia dell'initrd.
I problemi di block corruption di Oracle non sembrano risolti, però. Non riesco proprio a capire a che cosa siano dovuti.

Intanto segnalo un'interessante commento di Howard Rogers sui sistemi a 64 bit di classe desktop (AMD64, EM64T); sono utili o no? Per i database sembra proprio di sì, ma non vorrei che i problemi da me riscontrati indichino che ci si sta avvicinando al limite di performance.

Sto facendo prove di installazione di 11g, ma serve per forza un sistema a 32 bit. Ancora un po' di pazienza :-)

24 agosto 2007

Query cache, result cache

Tra le nuove caratteristiche di 11g ce n'è una che sembra proprio presa o perlomeno ispirata dal "giocattolo" mysql: la query cache.
Tom Kyte ha prontamente scritto un notevole articolo sulla nuova feature di Oracle sull'ultimo numero di Oracle Magazine.
È utile un confronto con la query cache di mysql, il cui funzionamento è spiegato nel dettaglio nella pagina "how", dove si intuiscono perfettamente le ragioni delle limitazioni della query cache rispetto alle operazioni normali. Già una piccola differenza con Oracle è la modalità di utilizzo della feature: in mysql è a livello istanza, mentre in Oracle è a livello optimizer, quindi a livello query, e funziona quindi anche all'interno di procedure (mentre in mysql no: evidentemente considera solo l'hash value della testo, sbagliando).
Già questo basterebbe a fare una enorme distinzione sull'uso della memoria cache, visto che con Oracle bisogna specificare per ogni singola query se si vuole cachare il risultato, impedendo così la frammentazione e il riempimento inutile della cache, nonché la rimozione inopportuna di resultset utili per accogliere query che non dovrebbero essere salvate.
Oracle può inserire in cache anche i risultati delle funzioni (sempre a comando), con un'interessante caratteristica in più: si possono definire gli oggetti da cui dipende il risultato della funzione, ottimizzando i controlli che il db dovrebbe fare ad ogni esecuzione.

22 agosto 2007

Prove Oracle 11g e new features

Sto facendo le prime prove di Oracle 11g (database, ovvio :-)). Il logo dei "bidoni di petrolio" in immagine è quello originale.
Per primo ho installato il CD client, stranamente subito disponibile come download. L'installazione, su OpenSuSE 10.2 x86, è semplicissima e finalmente vedo che Oracle ha abbandonato l'ormai inutile controllo del prerequisito che il sistema operativo sia tra quelli supportati, almeno all'avvio dell'installazione. L'installazione client fa scegliere ancora tra le tipologie programmatore-amministratore; l'installazione più massiccia è quella di amministratore ma... sorpresa! Non ho capito dove sono gli eseguibili, o meglio dove sta l'Enterprise Manager della situazione, visto che il wrapper oemapp sembra sia sparito. In compenso è comparso SQLDeveloper, che quindi probabilmente sostituisce gran parte delle funzioni del "vecchio" EM in formato Java; peccato però non mantenerlo, secondo me un'applicazione a due livelli come il vecchio EM è insostituibile in molte situazioni; rimane comunque disponibile sul CD client del vecchio 10g :-).

Intanto leggiamo il manuale delle new features.
Nelle prime righe c'è una "clamorosa" aggiunta: la query cache! Sì, proprio quella di mysql. Bisogna controllare però gli algoritmi di manutenzione della cache, che in mysql sostanzialmente ne limita(va)no moltissimo l'utilizzo. Una differenza enorme, a quanto sembra, è la presenza della query cache sia sul server che su client. Troppo anvanti. Sono troppo curioso di vedere quali sono i limiti dovuti alle operazioni DDL e DML e il confronto con mysql.
Ora il connection pooling non è più riservato alle applicazioni multithread, ma anche a robe più semplici come PHP.
Gli standby possono essere interrogati in tempo reale, mentre viene applicato il redo. Finalmente! Non solo: gli standby possono essere aperti temporaneamente anche in lettura e scrittura (questa, poi!). Vedremo in futuro come funziona questa cosa nel dettaglio.
Ora i comandi DDL hanno il WAIT di default, che evita il controllo degli errori di locking esclusivi.
La ricostruzione online degli indici non ha più stati di attesa di DML lock.
C'è il nuovo comando ALTER TABLE table_name READ ONLY per evitare che anche il proprietario di una tabella la possa modificare.
C'è il nuovo parametro MEMORY_TARGET, che volendo sostituisce SGA_TARGET e PGA_AGGREGATE_TARGET.
ORACLE_BASE diventa la variabile di riferimento per le installazioni.

Nel frattempo non ho trovato nulla sul contenuto di questo strano client CD. Se dovessi trovare qualcosa vi avviso :-)

21 agosto 2007

MySQL 5 secondo Alex Papadimoulis

Ricordate Alex Papadimoulis, il creatore del magnifico Daily WTF? A quanto pare ha anche un blog, in cui ho trovato un'ottima digressione su MySQL 5 e i suoi tradizionali aspetti controversi. Ottimo.

20 agosto 2007

Oracle 11g GA

Mentre ero in vacanza :-) Oracle ha rilasciato la prima versione del database 11g, disponibile per il download, come sempre.
Ora il mio megaserver di casa avrà pane per i suoi denti, con una nuova ORACLE_HOME in aggiunta di quella sperimentale 10g.

A proposito di compatibilità, segnalo che i kernel OpenSuSE hanno una versione secondo me troppo vecchia del modulo SATA per i chipset nForce, e purtroppo la situazione non si può risolvere facilmente: nVidia mette a disposizione i sorgenti solo per le distribuzioni commerciali (es. SLES10). Speriamo che quelli della SuSE riescano ad inserire le modifiche nella nuova 10.3. Quasi quasi gli scrivo.

06 agosto 2007

Archivelog RAC su ASM

Gli archivelog di un cluster Oracle 10g su ASM possono finire, a seconda della configurazione, su molteplici destinazioni, ma quella preferenziale è sempre sullo storage condiviso, come per il resto del database.
Se archiviate anche su filesystem, e quindi per ogni server avete un thread di redo diverso, fate attenzione alla consistenza dei log archiviati localmente durante un'eventuale caduta di uno dei nodi del cluster. A me è capitata un'inconsistenza, risolta esportando l'archivelog da ASM, dove evidentemente non c'è stato un problema di salvataggio del thread. Come è possibile? Basta usare il la procedura DBMS_FILE_TRANSFER.COPY_FILE.
Attenzione che i parametri di COPY_FILE sono sempre dei directory object, non delle directory vere e proprie; corrispondono, ai fini pratici, ad alias di locazioni nello storage accessibile alle istanze, tra cui ovviamente c'è il filesystem ASM:
SQL> CREATE DIRECTORY dir_name AS '+ASM/ciao';
creando sia la directory sorgente che quella di destinazione.