SQLcl, UTF-8 e windows

giovedì 26 luglio 2018 alle 26:19 | Pubblicato su 12c, Diario, Installation and Configuration | Lascia un commento

Oggi ho provato a scaricare e vedere com’è l’ultima versione di SQL Developer, la 18.2. Ho dato una rapida occhiata e non ho visto cose stratosferiche. Il problema è che più invecchio più mi sento distante dall’informatica moderna dove tutti vogliono interfacce grafiche, mentre io mi ostino a usare  e preferire per molte attività interfacce a linea di comando. Continuo a non vedere grandi vantaggi. D’altra parte continuo a ritenere che i migliori sistemi sono quelli che hanno la possibilità di essere controllati con comandi a linea di comando che permettono di prepare script che rendono le attività ripetitive una cosa assai facile. Poi sopra ci si può implementare interfacce grafiche che aiutano per attività più sporadiche o per dare delle panoramiche di un sistema. Anche Oracle implementa tutto o quasi via SQL, poi c’è la console grafica Cloud Control che permette senz’altro una gestione globale e generale più facile. Ho un po’ divagato rispetto al tema che voglio trattare in questo post. Su SQL Developer ho visto un link a SQLcl, una sorta di sostituto di SQL*Plus, ovvero un client a linea di comando SQL. SQLcl mi sembra per molte cose compatibile con SQL*Plus ma con in più qualche miglioria, anche qui mi vien da dire non cose stratosferiche. Ho provato a vedere se c’è la “dynamic linesize”, come su SQL*Plus 18.1, ma non l’ho trovato, con un certo sconforto. Poi mi è venuto in mente di controllare come gestisce la codifica in UTF-8, al riguardo negli anni ho avuto sempre qualche problema ed ho scritto una serie di post, l’ultimo dovrebbe essere questo. Quel post è del 2013, siamo arrivati al 2018 e poco è cambiato. Ho fatto un rapido test per vedere come SQLcl gestisce la codifica e il risultato è stato negativo. Ho quindi fatto una rapida ricerca, arrivando qui. Credo di esserci gia passato qualche tempo fa ma probabilmente non ho avuto modo di approfondire ne’ scrivere qualcosa, ho quindi deciso di farlo oggi. Senza farla tanto lunga, per gestire un po’ la codifica di caratteri particolari in UTF-8 occorre, sotto windows sempre settare il font a “Lucida Console”, settare il codepage a 65001 (chcp 65001) e poi, non basta. A quanto pare SQLcl non usa le variabili d’ambiente, quindi settare o meno NLS_LANG=.AL32UTF8 come faccio con SQL*Plus non sembra fare differenza e lo stesso Jeff Smith afferma che non vengono lette variabili d’ambiente per settare gli NLS. Siccome quanto affermato nel post con la mia installazione di SQLcl su win7 non funziona,

-----------
Luned�
Marted�
Mercoled�
Gioved�
Venerd�
Sabato
Domenica

ho scorso i commenti, fino ad arrivare a questo. Le cose migliorano:

 Lunedì

 Martedì

 Mercoledì

 Giovedì

 Venerdì

 Sabato
 Domenica

C’è una anomalia nella formattazione che sembra che in coda al carattere accentato venga messo un accapo, anche se non è così… boh.

Le cose se facciamo una prova con una cosa tipo: “select ‘è’ from dual;” non vanno benissimo:


CRISTIAN@svil > select '�' from dual;



è

Che poi è sempre meglio di SQL*Plus:

CRISTIAN@svil > select 'è' from dual;
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

 

La risposta secondo me sta tutta in questo commento in cui Jeff Smith aspetta da MSFT un terminale decente…secondo me non c’è speranza

Annunci

Oracle Resource Manager con CDB e PDB

venerdì 15 giugno 2018 alle 15:42 | Pubblicato su 12c, Diario, Installation and Configuration, Performance Tuning | Lascia un commento

Con l’introduzione dell’architettura “multitenant” in Oracle 12 si sono stati degli aggiornamenti e delle estensioni al funzionamento di Oracle Resource Manager che è lo strumento per ripartire in base a determinate esigenze le risorse disponibili su un server.  Confesso di non aver mai potuto testare e vedere in azione veramente il resource manager, credo di avere fatto solo delle piccole prove per gestire sessioni inattive e bloccanti ma non sono andato oltre. Oltre dieci anni fa (!) ho scritto un mio riassunto di cui ho parlato in questo post.  Dopo tanto tempo ho l’ambizione di fare un post riassuntivo delle novità del resource manager nell’ambito di Container database e Pluggable database.

Con l’architettura multitenant si è aggiunto un livello ulteriore su cui gestire le risorse in un database Oracle. Per cui in Oracle 12 su un database CDB il resource manager lavora a due livelli:

  • a livello CDB, in cui smista le risorse fra i PDB
  • a livello di PDB che come nella versione precedente smista le risorse fra gli utenti del singolo PDB.

Faccio riferimento a questa sezione del manuale Oracle.

CDB Resource Plans

un CDB resource plan alloca le risorse ai PDB in base al suo insieme di direttive (resource plan directives).

C’è una relazione padre-figlio tra un CDB resource plan e le sue direttive. Ogni direttiva fa riferimento a un PDB e non ci possono essere due direttive nel piano correntemente attivo che fanno riferimento allo stesso PDB.

Le direttive controllano l’allocazione delle seguenti risorse ai PDB:

  • CPU
  • Parallel execution server.

Le direttive di un CDB resource plan sono molto semplici, hanno tre parametri:

  • SHARE: rappresenta la fetta di CPU e di parallel server riservata al PDB
  • UTILIZATION_LIMIT: è un limite superiore alla percentuale di CPU utilizzabile dal PDB
  • PARALLEL_SERVER_LIMIT: è un limite superiore percentuale (sul valore impostato tramite il parametro PARALLEL_SERVERS_TARGET)

Esiste una direttiva di default per i PDB per cui non è stata definita una direttiva e assegna uno share e un limite del 100% sia per UTILIZATION_LIMIT e PARALLEL_SERVER_LIMIT.   Questa direttiva può essere modifica con la procedura dedicata del package DBMS_RESOURCE_MANAGER UPDATE_CDB_DEFAULT_DIRECTIVE.

C’è poi un’altra direttiva predefinita, chiamata AUTOTASK che si applica ai task di gestione automatica (automatic maintenance tasks) che girano nel root duranto le finestre di manutenzione. Questa direttiva può essere modificata con la procedura UPDATE_CDB_AUTOTASK_DIRECTIVE

Una cosa curiosa, scritta sul manuale, è che se un PDB viene scollegato “unplugged” la direttiva che lo riferisce viene mantenuta e nel caso il PDB venga ricollegato viene riutilizzata. Qui ho una lacuna da colmare perché mi sembra di ricordare dai miei test che dopo l’unplug l’unica cosa che si può fare con un PDB e la rimozione, dopodiché si riesce a ricollegare; mi sembra strano che venga mantenuto un riferimento a un PDB rimosso… spero di poter fare una prova al riguardo.

PDB Resource Plans

A livello di PDB si definiscono dei piani in maniera analoga a quanto si faceva prima su database non-CDB, ci sono però dei limiti:

  • un PDB resource plan non può avere sottopiani
  • un PDB resource plan può avere un massimo di otto consumer group
  • un PDB resource plan non può avere politiche di schedulazione multi-livello (multiple-level scheduling policy)

Se si collega come PDB un database non-CDB che ha dei resource plan che non rispettano i vincoli sopra Oracle modificherà i piani per farli rientrare nei vincoli.

P.S. 18/06/2018

sono riuscito a fare una prova riguardo al definire un CDB plan con delle direttive che fanno riferimento a un PDB. Ho fatto successivamente l’unplug e poi il drop del PDB ed effettivamente la direttiva che riferisce il pluggable database rimosso rimane.

Copiare, spostare o rinominare un datafile in Oracle

martedì 12 giugno 2018 alle 12:05 | Pubblicato su 12c, Diario, Installation and Configuration | 2 commenti

Breve post promemoria sui concetti che si possono trovare su questa parte dei manuali Oracle. Il motivo per cui lo faccio è che faccio fatica a memorizzare la sintassi dei vari comandi Oracle e con la versione 12.1 c’è la possibilità di copiare o spostare o rinominare i file “online”.  Per supportare questa nuova funzionalità Oracle ha introdotto una nuova sintassi, il comando è:

ALTER DATABASE MOVE DATAFILE ( ‘filename’ | ‘ASM_filename’ | file_number )
[ TO ( ‘filename’ | ‘ASM_filename’ ) ]
[ REUSE ] [ KEEP ]

Il bello di questo comando è che si occupa lui anche di copiare “fisicamente” il file. L’unica restrizione che trovo sul manuale è che il datafile deve essere in modalità “online” altrimenti il comando restituisce errore. Pare quasi una banalità…

Nella modalità pre-12 c’erano due possibili comandi:

  • ALTER DATABASE RENAME FILE…

  • ALTER TABLESPACE <tbsname> RENAME DATAFILE …

 

in entrambi in casi occorre prima portare i datafile offline in qualche modo (nel secondo si può mettere offline solo la tablespace interessata, nel primo si può mettere in stato mount l’intero database, questo nel caso la rinomina o lo spostamento riguardi più file…) in questo caso poi, dopo aver portato in modalità offline i file occorre, prima di eseguire i comandi copiare/spostare/rinominare i file “manualmente”,  il comando si limita ad aggiornare le informazioni registrate sul controlfile.

Gestione Audit su database Oracle

giovedì 1 febbraio 2018 alle 01:05 | Pubblicato su 11g, 12c, Diario, Installation and Configuration | Lascia un commento
Tag:

Il titolo del post è pretenzioso e di fatto non rispecchia il vero contenuto in quanto coprire l’argomento “Audit” in Oracle è una cosa abbastanza difficile per la sua complessità. Il manuale “Security Guide” della versione 12.1 copre l’argomento con tre capitoli. Vi sono poi un po’ di novità sulla versione 12.1 rispetto alla 11.2. E’ un argomento su cui faccio fatica a raccapezzarmi, quindi provo ad affrontarlo per gradi.

Il post precedente è un esempio di quanto faccia fatica a dedicarmi all’approfondimento di nuovi (per me) temi. Cerco di rimediare alla confusione di quel post con un post più specifico e spero più ordinato e preciso in cui parlo esclusivamente della gestione della pulizia degli “audit” generati da Oracle.

Comincio con una informazione certificata dal supporto Oracle con la nota 308066.1 la quale spiega che anche con i parametri audit_trail=NONE e audit_sys_operations=FALSE vengono generati sotto il percorso indicato dal parametro audit_file_dest dei file .aud. In particolare vengono sempre e comunque generati dei file in cui si registrano le connessioni con utenti SYSDBA o SYSOPER e le operazioni di avvio e arresto dell’istanza. Questo vale sia per Oracle 11.2 che 12.1

Ora, i file sono piccoli ma possono diventare numerosi, nel mio caso ci sono procedure che si collegano con utenze privilegiate per fare dei controlli automatici e quindi vengono generati centinaia di file al giorno. Dopo qualche mese i file diventano migliaia. Da notare che se il filesystem si riempie non si riesce neppure ad accedere al database con l’utenza SYSDBA perché il sistema si lamenta di non riuscire a scrivere il file di audit. Ora, per gestire tutti i tipi di Audit Oracle mette a disposizione un package PL/SQL che si chiama DBMS_AUDIT_MGMT. I tipi di Audit che Oracle gestisce sono diversi, con la versione 12 è stato introdotto lo UNIFIED Audit Trail per mettere in un unico posto tutte le informazioni ma per retrocompatibilità esistono i tipi presenti nella versione precedente e questi sono:

  • File xml (AUDIT_TRAIL_XML)
  • File normali (AUDIT_TRAIL_OS
  • Record standard sulla tabella SYS.AUD$
  • record di Fine Grained Audit (FGA) sulla tabella SYS.FGA_LOG$)
  • Per la 12 record sulla vista UNIFIED_AUDIT_TRAIL

Ora per ciascuno di questi “canali” di audit c’è una costante nel package DBMS_AUDIT_MGMT.

Se ci si vuole limitare alla pulizia dei file .aud senza alcun criterio particolare il modo più semplice è l’uso della procedura DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL in questo modo:

BEGIN
 DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
 USE_LAST_ARCH_TIMESTAMP => FALSE );
END;
/

Con l’aiuto della procedura DBMS_AUDIT_MGMT.CREATE_PURGE_JOB si può pianificare una pulizia automatica periodica, ad esempio:

begin
 DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS, 
 AUDIT_TRAIL_PURGE_INTERVAL => 24,
 AUDIT_TRAIL_PURGE_NAME => 'OS_Audit_Trail_PJ',
 USE_LAST_ARCH_TIMESTAMP => FALSE );
END;
/

Con gli esempi sopra vengono eliminati solo gli audit su file, se si vuole eliminare tutto, quindi ad esempio anche il contenuto della tabella AUD$ occorre fare un passo preliminare di inizializzazione. Occorre utilizzare la procedura DBMS_AUDIT_MGMT.INIT_CLEANUP che stando alla documentazione semplicemente sposta le tabelle dalla tablespace SYSTEM a SYSAUX, cosa che forse è sempre e comunque utile (al punto da chiedersi perché Oracle non le metta direttamente li in automatico. Infatti con lo unified audit trail è così). Quindi, ad esempio:

BEGIN
 DBMS_AUDIT_MGMT.INIT_CLEANUP(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 DEFAULT_CLEANUP_INTERVAL => 12 );
END;
/

La nota del supporto Oracle 1243324.1 riferendosi a Oracle 10.2.0.5 riferisce che il parametro DEFAULT_CLEANUP_INTERVAL è di fatto inusato, non mi è chiaro se cambia qualcosa sulle versioni 11 e 12.  Di sicuro l’intervallo da indicare sulla procedura CREATE_PURGE_JOB è obbligatorio e quello viene usato.

begin
 DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL, 
 AUDIT_TRAIL_PURGE_INTERVAL => 24,
 AUDIT_TRAIL_PURGE_NAME => 'ALL_Audit_Trail_PJ',
 USE_LAST_ARCH_TIMESTAMP => FALSE );
END;
/

 

Su Oracle 12 le procedure hanno dei parametri in più per gestire l’architettura multitenant, quindi nel mio caso alla procedura CREATE_PURGE_JOB ho aggiunto il parametro:

 container=>DBMS_AUDIT_MGMT.CONTAINER_ALL

Il default del parametro “container” è CONTAINER_CURRENT.

Combinando in maniera saggia i parametri o usando il parametro LAST_ARCHIVE_TIMESTAMP si possono organizzare politiche più elaborate; alla fine, capiti i concetti di base le cose sono abbastanza semplici e facili da capire

Manutenzione log e audit in Oracle

martedì 30 gennaio 2018 alle 30:35 | Pubblicato su 11g, 12c, Diario, Installation and Configuration | Lascia un commento
Tag:

Una cosa che non ho mai realmente approfondito, prima di adesso, era la manutenzione e pulizia dei vari file di log che un database server Oracle genera. In realtà, in condizioni normali, non c’è questo gran bisogno di fare manutenzione, per questo non me ne sono mai curato seriamente.  Ultimamente però mi è capitato spesso di dover fare pulizia in emergenza, in particolare ho avuto difficoltà con i file generati dal sistema di “Auditing” di Oracle. Il sistema di Auditing di Oracle fra l’altro è una cosa che nelle ultime versioni si è evoluto ed è abbastanza complesso.  Senza entrare quindi troppo nel dettaglio mi limito a dire che sembra che in qualunque condizione Oracle generi sempre e comunque un nuovo file .aud sotto $ORACLE_BASE/admin/<dbname>/adump ogni volta che avviene un accesso con una utenza SYSDBA. A causa di sistemi che fanno accessi automatici con questa utenza mi sono trovato quindi dopo un breve periodo di attività un numero esorbitante di file .aud. Il fatto è che oltre un certo numero anche rimuoverli con un semplice “rm” diventa difficile perché si ottiene un errore perché il sistema si lamenta che la lista dei file è troppo lunga…. Per un po’ ho sopperito come potevo manualmente, poi ho deciso di affrontare la questione in modo un po’ più  serio. Ho verificato quanto si riporta qui, ovvero che la generazione di questi file non può essere disattivata, infatti confermo che continua anche impostando il parametro AUDIT_TRAIL al valore “NONE”. Quello che è più importante secondo me di quel post è il primo commento, il quale riporta una procedura abbastanza semplice per gestire in modo automatico la pulizia di questi file direttamente da Oracle. Si tratta di usare il package PL/SQL DBMS_AUDIT_MGMT. Io al momento ho semplificato con queste tre chiamate:

BEGIN
 DBMS_AUDIT_MGMT.INIT_CLEANUP(
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
 DEFAULT_CLEANUP_INTERVAL => 1 );
END;
/
exec sys.dbms_audit_mgmt.set_last_archive_timestamp(audit_trail_type => sys.dbms_audit_mgmt.audit_trail_os,last_archive_time => sysdate - 3);
BEGIN
 DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
 AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL, 
 AUDIT_TRAIL_PURGE_INTERVAL => 1,
 AUDIT_TRAIL_PURGE_NAME => 'ALL_Audit_Trail_PJ',
 USE_LAST_ARCH_TIMESTAMP => TRUE );
END;
/

 

Di fatto viene schedulato un “job” di pulizia dei file di audit. Prima di poter creare il job vero e proprio occorre fare una inizializzazione. Secondo la documentazione uno dei passi dell’inizializzazione è spostare le tabelle su cui vengono registrati i dati di audit dalla tablespace SYSTEM a SYSAUX. In effetti ho avuto su un paio di database, durante la chiamata della procedura INIT_CLEANUP, errori di spazio sulla tablespace SYSAUX. La cosa bizzarra è che anche se la tablespace era in autoestensione la procedura mi dava errore comunque, l’unico modo quindi è allocare manualmente lo spazio espandendo il datafile.

La procedura CREATE_PURGE_JOB crea il “job” che si occuperà della pulizia dei file (e per come l’ho impostato io anche dei dati a db) più vecchi. Il punto è stabilire il periodo di ritenzione. Infatti la procedura di pulizia posso confermare gira appena si crea il job, poi dovrebbe girare secondo la schedulazione impostata, nel mio caso ogni ora (forse è un po’ esagerato ma sono ancora in fase sperimentale).  Senza la chiamata di SET_LAST_ARCHIVE_TIMESTAMP non si otterrà molto. Infatti il principio è che bisogna prima “archiviare” i file, quindi si dice a Oracle fino a che data e ora  i dati sono stati archiviati e così Oracle con il job schedulato li cancellerà….. ora il dubbio che mi è venuto scrivendo è che se non aggiorno almeno periodicamente il timestamp con la chiamata di quella procedura il job di cancellazione dopo la prima chiamata non cancellerà più nulla. Ipotizzo sia così ma mi riservo di verificare nei prossimi giorni. In ogni caso va detto che uno dei pregi di queste procedure è che sono molto rapide, nel mio caso con centinaia di migliaia di file l’operazione è stata molto più rapida che non a farla cancellando i file a mano.

Molto banalmente, leggendo la documentazione ho capito che, se non mi interessa un tubo degli audit, basta chiamare la procedura di creazione del job con il parametro USE_LAST_ARCH_TIMESTAMP  a false, secondo la documentazione il job in questo modo cancellerà tutto.

Un’altra parte importante di gestione log è la gestione del cosiddetto ADR, Automatic Diagnostic Repository, il posto dove Oracle scrive log e trace vari.  In questo caso Oracle prevede gia per default delle procedure di pulizia di questa area. Utilizzando l’utility ADRCI con il comando “show control” si possono estrapolare i due parametri SHORTP_POLICY e LONGP_POLICY che indicano il periodo di ritenzione in ora per rispettivamente per quelli che Oracle definisce file di “breve vita” e “lunga vita”. Per default i valori sono rispettivamente 30 giorni e 365 giorni. A parte l’inghippo derivante alla possibilità di avere più “homes” i valori si possono facilmente modificare con i comandi “set control” ad esempio nel mio caso:

set control (shortp_policy=100)
set control (longp_policy=300)

 

In automatico sembra che la pulizia giri o due giorni dopo l’avvio dell’istanza o ogni 7 giorni (note oracle 1196437.1 e 1446242.1). Per forzare una pulizia immediata basta il semplice comando “purge”

L’unico inghippo è il file alert in formato testo che si trova sotto la directory trace, quello non viene gestito da adrci, quindi va gestito a “mano”, si può fare tranquillamente a caldo facendo da sistema operativo un “mv”. (conferma qui)

Rileggendo velocemente il post, scritto abbastanza in fretta mi rendo conto sia un po’ confuso, come confusa è stata la mia ricerca a causa della scarsità di tempo a disposizione. Siccome però il tempo continuerà a scarseggiare per ora lo pubblico così e spero poi di poter fare qualche approfondimento.

Standby database per Oracle standard edition 11gR2

mercoledì 15 gennaio 2014 alle 15:36 | Pubblicato su 11g, Installation and Configuration | Lascia un commento
Tag: , ,

Sono passati oltre quatto anni da quando scrissi questo post in cui parlai dell’implementazione del sistema di disaster recovery basato sullo standby database su Oracle standard edition. Qualche tempo fa mi è stato chiesto se eravamo in grado di mettere in piedi questa soluzione, siccome però sono passati gli anni  però, ora la nostra versione di riferimento è oracle 11.2 e non più 10.2 con la quale feci i test a suo tempo. C’è da dire che a suo tempo ho anche messo in piedi una implementazione completa, con tutta la gestione automatizzata del trasferimento degli archived log e della loro applicazione sullo standby database su una installazione con Oracle 9.2.

Con un po’ di pazienza sono riuscito a crearmi un ambiente virtualizzato (con virtual box, che per questi test sembra funzionare molto bene). Ho creato quindi una macchina virtuale con Oracle Linux 6.3 64 bit, vi ho installato Oracle Database 11.2.0.3. A questo punto ho clonato la macchina e in qualche modo ho sistemato il nome e l’indirizzo IP. Ho creato un database sulla prima macchina, poi ho seguito i miei appunti usati a suo tempo per Oracle 9.2 per creare lo standby database e fare qualche prova: il risultato è che funziona tutto allo stesso modo in cui funzionava su Oracle 9.2 e Oracle 10.2. L’unico inghippo l’ho riscontrato quando ho fatto un test che forse a suo tempo non avevo fatto: l’aggiunta di una nuova tablespace con relativo database; in questo caso mi sono imbattuto nel problema ben descritto qui, così ho scoperto l’esistenza del parametro STANDBY_FILE_MANAGEMENT. Per rendermi la vita facile quello che ho fatto è stato di modificare il parametro e ricreare da zero lo standby database.

Ieri sono riuscito a fare un ulteriore test, il cui esito al momento pare positivo, cioè applicare l’aggiornamento alla versione 11.2.0.4.  Mi sono trovato un po’ spiazzato con questo aggiornamento, per due motivi: il primo è che non ho trovato al suo interno le solite istruzioni (ho trovato la guida “Upgrade” fra la documentazione ufficiale ma questa, a voler essere pignoli, si riferisce alla versione 11.2.0.3; il secondo motivo di spiazzamento è che fare l’aggiornamento “in-place” è stato reso complicato da Oracle. Ho trovato comunque lo spazio per fare l’aggiornamento “out-of-place” come richiesto, quindi creando una nuova Oracle Home. Alla fine della parte di aggiornamento della parte “software” l’installer lancia automaticamente DB Upgrade Assistant (DBUA) che nonostante i miei timori ha eseguito la parte di aggiornamento del database senza errori.

Il bello però viene nell’aggiornamento dello standby database. La mia idea era quella di aggiornare il software e sperare che la sincronizzazione tramite l’applicazione degli archived logs funzionasse aggiornando anche lo standby database. Ciò che è accaduto è che lanciando anche sullo standby l’installer di 11.2.0.4 è andato tutto bene fino alla parte di aggiornamento del software, poi è partito DBUA il quale però manco trovava le informazioni sul database da aggiornare, in quanto in effetti non aveva le informazioni registrate sul file /etc/oratab. Poco male, anzi stavo per aggiungerle quando mi sono reso conto che comunque DBUA non avrebbe potuto fare nulla perché lo standby database non è apribile in scrittura (se non con una switch-over) . Io qui ho interrotto la procedura ed ho provveduto manualmente ad applicare gli archived logs generati sul primary e tutto pare aver funzionato bene, ho fatto nuovi test e pare funzionare come atteso (l’unica cosa che non ho detto è che ho copiato il contenuto della directory “dbs” dalla vecchia alla nuova Oracle Home.

Prossimamente conto  di fare lo stesso test con Oracle 12.1

Ancora Character Set, ORA-00600 [kafspa:columnBuffer2]

giovedì 1 agosto 2013 alle 01:55 | Pubblicato su 11g, Diario, Installation and Configuration, Varie | Lascia un commento
Tag: , ,

Non c’è dubbio che la gestione del Character Set sui database Oracle sia una cosa tutt’altro che banale e poco chiara ai più. Ieri controllando i log di un database interno utilizzato per i test ho trovato il seguente errore:

ORA-00600: internal error code, arguments: [ORA-00600: internal error code, arguments: [kafspa:columnBuffer2], [4053], [4000], [], [], [], [], []

Il database è un 10.2.0.5 su linux 64 bit, recentemente migrato da una vecchia macchina dove c’era però una versione 10.2.0.3. Ho passato i dati dal vecchio database al nuovo tramite expdp/impdp dei vari schemi (approfittando per fare un po’ di pulizia). L’errore veniva generato durante il calcolo delle statistiche notturno e nell’alert.log c’era rimando a un file di trace su cui ho trovato anche dettagli sulla tabella che provocava l’errore. Il secondo e terzo argomento dell’errore ORA-00600 mi ha fatto subito sospettare il tipo di problema (che fra l’altro in forme diverse ho gia incontrato altre volte. In effetti ho individuato nella tabella un campo definito come VARCHAR2(4000) facendo una query simile a questa:


SELECT NOMECAMPO FROM NOMETABELLA WHERE LENGTH(NOMECAMPO)>4000

ottenevo sempre l’errore  ORA-00600.

Facendo una ricerca sul supporto Oracle ho trovato poco, facendone una Google sono arrivato qui, come dire: a volte ritornano. Infatti in coda al post che non ricordavo di aver gia letto ho trovato dei miei commenti. Avendo anche cambiato il titolo del blog non mi ricordavo neanche chi fosse l’autrice 🙂

In realtà ho scoperto con un po’ di sorpresa che lo schema proveniva in effetti da un dump fornitoci dal cliente, che però io credevo avesse database con character set UTF-8 solo di recente sono riuscito a scoprire che in realtà il cliente utilizza charset ISO8859-15 e che quindi ero incappato sullo stesso problema. Il bello è che per trovare una soluzione, dopo alcuni banali tentativi per isolare i record con stringhe lunghe più di 4000 byte all’interno del campo incriminato, ho provato a fare un export con data pump e importare la tabella su un’altro schema dello stesso database, con una certa sorpresa mi sono trovato sul nuovo schema una copia della tabella con lo stesso problema.

Dopo vari esperimenti, alla fine, sfruttando la chiave primaria della tabella, che è un id generato da sequence,  ho isolato un record con il problema; in realtà ho trovato anche altri 6 record che su un campo varchar2(600) avevano stringhe che occupavano ben più di 600 byte ma questi record creavano problemi solo nei tentativi di CREATE TABLE AS …

In teoria ho risolto facendo un update sul campo per chiave:


UPDATE NOMETABELLA SET NOMECAMPO=SUBSTR(NOMECAMPO,1,4000) WHERE CAMPOCHIAVE=XXX

che con un certo mio sconcerto ha funzionato (apparentemente), in seguito ho fatto alcune prove, compreso il ricalcolo delle statistiche, senza riscontrare problemi, stamattina però nell’alert.log ho ritrovato l’errore sulla stessa tabella, in realtà mi aspettavo di trovare l’errore sulla copia che ho mantenuto con l’errore per fare ulteriori verifiche è così è stato anche se in un primo momento non era chiaro guardando il trace.

Stamattina ho avuto modo di fare ricerche più approfondite e mirate sul problema, leggendo nota del supporto Oracle intitolata:

“Changing the NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET (Doc ID 1283764.1)”

al paragrafo 1.d ho trovato la seguente frase:

Do NOT use Expdp/Impdp when going from (AL32)UTF8 to a single byte NLS_CHARACTERSET on ALL 10g versions lower then 10.2.0.4 (including 10.1.0.5). Also 11.1.0.6 is affected.
It will provoke data corruption unless Patch 5874989 is applied on the Impdp side. Expdp is not affected, hence the data in the dump file is correct.Also the “old” exp/imp tools are not affected.
This problem is fixed in the 10.2.0.4 and 11.1.0.7 patch set.
Fixed in 11.2.0.1 and up

 

che mi ha un po’ illuminato. In realtà ho dovuto un po’ ricostruire la storia. Sul nostro nuovo database di test 10.2.0.5 (che dovrebbe essere esente dal bug) ho due schemi dello stesso cliente, uno importato direttamente dal dump fornito dal cliente e su cui non si presenta il problema, infatti nei log dell’import trovo:

ORA-02374: conversion error loading table “SCHEMA2″.”NOMETABELLA”
ORA-12899: value too large for column NOMECAMPO (actual: 3995, maximum: 4000)
ORA-02372: data for row:

L’altro schema, sui ho trovato il problema, proveniva dallo stesso dump, ma era passato prima dal vecchio database 10.2.0.3, quindi era stato importato sul vecchio db, dove si era generata la corruzione (senza che io me ne accorgessi), poi da li è stato esportato  e importato sul nuovo database, senza errori nei log di data pump. Mi pare quindi che Oracle abbia corretto parzialmente il problema, perché impdp non genera più la corruzione sulla tabella ma scarta i dati in importazione, però, se la tabella è gia corrotta essa viene esportata e importata da datapump tale e quale, corruzione compresa. Prossimamente conto di provare a fare dei test su un Oracle 11.2.0.3, magari se ne trovo uno con character set ISO8859 posso fare dei test più completi.

Riguardo la gestione del character set su Oracle riporto qui un paio di riferimenti a note Oracle che vale la pena leggere:

  • AL32UTF8 / UTF8 (Unicode) Database Character Set Implications (Doc ID 788156.1)
  • Changing the NLS_CHARACTERSET From AL32UTF8 / UTF8 (Unicode) to another NLS_CHARACTERSET (Doc ID 1283764.1)
  • NLS_LANG Explained (How does Client-Server Character Conversion Work?) (Doc ID 158577.1)

Installazione Oracle Enterprise Linux 4 update 4 32 bit

martedì 24 aprile 2012 alle 24:47 | Pubblicato su 11g, Installation and Configuration, Linux | 2 commenti

A scopo di test mi sono trovato a installare su un vecchio PC una versione di Oracle Enterprise Linux (OEL) sulla quale poi installare Oracle Database 11.2, il tutto a 32 bit, essendo la macchina dotata di CPU pentium 4 HT a 32 bit. Ho avuto qualche fastidio, ad esempio per motivi che non ho ben compreso l’installazione dell’ultimissima release di OEL, la 6 update 2 si blocca al caricamento del kernel, quindi ho optato per una versione coeva del PC, una 4 update 4 che avevo gia a disposizione su CD in sede; anche con questa versione ho avuto problemi in quanto forse i CD sono un po’ rovinati, quindi arrivato al terzo CD non riusciva a leggere un pacchetto per cui ho dovuto ripartire da capo, riducendo al minimo i pacchetti da installare così da riuscire ad escludere completamente dall’installazione il terzo CD. Finita l’installazione mi sono ritrovato con un problema che avevo gia riscontrato tanto tempo fa e di cui mi ricordo di avere trovato la soluzione  sul blog di Howard Rogers (http://www.dizwell.com/), che però nel frattempo è cambiato e i vecchi post non sono più pubblici; il problema è che il menù “Applications” del desktop manager Gnome risulta vuoto. Ho provato allora come prima cosa, ad aggiornare la release di Linux (comunque requisito minimo per installare la versione 11.2 del database server è avere una 4 update 7) e con yum ho provato ad aggiornare direttamente all’ultima update disponibile che è la 4  update 9, però qualcosa non ha funzionato. Probabilmente non è possibile passare direttamente dalla 4.4 alla 4.9, ho però cercato di “forzare”, facendo un


yum update enterprise-release

Subito ho sospettato che qualcosa non fosse andato per il verso giusto perché è stato troppo veloce, di fatto mi ha aggiornato solo il file /etc/enterprise-release, apparentemente senza controllare dipendenze. Il bello è venuto quando ho provato a fare un


yum remove enterprise-release

Questa volta sembra abbia controllato bene le dipendenze, rimuovendo tutto e distruggendo di fatto l’installazione linux. Ho quindi rifatto tutto, ho aggiornato Linux per passi, prima alla 4.5, poi alla 4.6, poi alla 4.7, poi alla 4.8 e infine alla 4.9.

Finito l’aggiornamento il problema del menù “Applications” vuoto permaneva. Non che sia un problemone, ma mi sono impuntato e alla fine ho trovato questo post che mi ha dato la soluzione indicandomi il file /etc/xdg/menus/applications.menu, in realtà nella mai installazione era presente solo un file /etc/xdg/menus/applications2.menu che ho copiato su /etc/xdg/menus/applications.menu risolvendo il mio problema.

Data Pump e la compressione al volo

lunedì 18 luglio 2011 alle 18:03 | Pubblicato su Installation and Configuration, Linux | 7 commenti
Tag: , , ,

Solo oggi mi sono scontrato con un piccolo inconveniente di Oracle Data Pump. Siccome ho l’impressione di esserci gia passato e non voglio dimenticarmente ne approfitto per un nuovo post.

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.

Import tradizionale e cambio tablespace

martedì 15 febbraio 2011 alle 15:30 | Pubblicato su Installation and Configuration, Varie | 3 commenti

Oggi tratto un argomento vecchio, benché Oracle 10g e Data Pump siano stati rilasciati da molti anni e questa utility per esportare su file parti di database sia stabile, comoda e flessibile, mi capita ancora di dover maneggiare file di dump creati con le vecchie versioni del programma di export di Oracle, se non altro perché ho ancora a che fare con database versione 9.2

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.

Pagina successiva »

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