Modulo DBD::Oracle Client 19C

Nell’articolo Modulo DBD::Oracle Client 19C descrivo il modo di collegarsi al database Oracle attraverso il modulo Perl DBD::Oracle.
Girando per il Web ho trovato molte guide interessanti, ma anche molto confusionarie e incomplete.

Quindi ho deciso di fare un tutorial in cui spiego i vari step e problemi incontrati.

Obbiettivo dell’attività: permettere la connessione al DB Oracle 19C attraverso un client Oracle e il modulo Perl DBD::Oracle installati su un Application Server con OS Linux Centos 8.

Per eseguire il test ho utilizzato un Database Oracle 19C con architettura Standalone su un server con IP 192.168.3.10, database SID TEST, porta 1521.

L’installazione Perl è stata effettuata sull’Application Server con IP 192.168.3.11 con un utente perl con permessi di sudoers.

Prima operazione da effettuare, scaricare il client Oracle dal seguente link: https://www.oracle.com/it/database/technologies/instant-client/linux-x86-64-downloads.html

I software da scaricare sono i seguenti:

Basic Package (RPM)

wget https://download.oracle.com/otn_software/linux/instantclient/199000/oracle-instantclient19.9-basic-19.9.0.0.0-1.x86_64.rpm

SQL*Plus Package (RPM)

wget https://download.oracle.com/otn_software/linux/instantclient/199000/oracle-instantclient19.9-sqlplus-19.9.0.0.0-1.x86_64.rpm

SDK Package (RPM)

wget https://download.oracle.com/otn_software/linux/instantclient/199000/oracle-instantclient19.9-devel-19.9.0.0.0-1.x86_64.rpm

Adesso procediamo con l’installazione del software Oracle con il seguente comando:

yum install oracle-instantclient19.9-basic-19.9.0.0.0-1.x86_64.rpm
yum install oracle-instantclient19.9-sqlplus-19.9.0.0.0-1.x86_64.rpm
yum install oracle-instantclient19.9-devel-19.9.0.0.0-1.x86_64.rpm

Dopo aver installato il Client Oracle, passiamo alla configurazione delle variabili nel file /home/perl/.bash_profile

vi /home/perl/.bash_profile
export ORACLE_BASE=/usr/lib/oracle/
export ORACLE_HOME=/usr/lib/oracle/19.9/client64/
export PATH=$ORACLE_HOME/bin:$PATH
export TNS_ADMIN=/usr/lib/oracle/19.9/client64/lib/network/admin export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/home/perl/perl5/lib export ORACLE_USERID="system/[email protected]" export ORACLE_DSN='dbi:Oracle:TEST'

Inserite le variabili passiamo alla configurazione del tnsnames.ora del client quindi, pendiamo la connect string dal tnsnames.ora del DB Server ed inseriamola nel file:

vi /usr/lib/oracle/19.9/client64/lib/network/admin/tnsnames.ora
TEST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.3.10)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = TEST)
)
)

A questo punto testiamo la connessione. Dovete essere in grado di accedere al database con il seguente comando:

sqlplus system/[email protected]

Se riuscite ad entrare possiamo passare all’installazione di Perl e dei moduli che permettono di sfruttare la connessione attraverso il client Oracle 19c.

Modulo DBD::Oracle Client 19C

L’installazione di Perl avviene con il seguente comando:

yum install perl perl-DBI perl-YAML -y

Scarichiamo il file DBD-Oracle-1.80.tar.gz con il seguente comando:

wget https://www.cpan.org/modules/by-module/DBD/MJEVANS/DBD-Oracle-1.80.tar.gz

Spacchettiamo il file .tar.gz con il seguente comando:

tar xzvf DBD-Oracle-1.80.tar.gz

Entriamo nella directory ed eseguiamo la compilazione del Modulo con i seguenti comandi:

cd DBD-Oracle-1.80
perl Makefile.PL
make
make test

Se il test termina con esito positivo, anche se non dovesse collegarsi all’istanza procediamo con il comando:

install

Se tutto è andato bene, a questo punto dovreste essere in grado di potervi collegare al database Oracle attraverso un script perl.

Nei prossimi giorni l’articolo sarà implementato con la procedura d’installazione attraverso cpan e alcuni script di connessione all’istanza Oracle.

Export e import in data pump

Nell’articolo Export e import in data pump presento le principali modalità di migrazione dati da un database ad un altro.

Una delle soluzioni migliori per migrare un database, è attraverso l’export e import in data pump.

Il tool è stato introdotto dalla versione Oracle 10g, rispetto alle versione exp/imp sono state introdotte nuove modalità di gestione e aumento delle performance.

L’export in datapump salva i dati a livello logico in uno o più file sul sistema operativo.

La directory in cui viene depositato il file deve essere registrata nel database quindi o controlliamo una directory già presente con il seguente comando:

select * from dba_directories;

Oppure va creata con il seguente comando:

create or replace directory DIR_PROVA as '/path/dump/dir/';

Il secondo controllo che va effettuato sempre, è la dimensione dello SCHEMA che sarà da esportare.

Il controllo può essere effettuato con la seguente query:

select owner,sum(bytes/1024/1024) MB from dba_segments where owner='&owner' group by owner;

Una volta individuata la dimensione dello SCHEMA e la directory dove depositare il dump di export, dovete verificare la presenta di spazio sul FS dove sarò creato il file dump e il file log.

Passiamo al comando di export.

Per comporre il comando che esegue l’eportazione dei dati dobbiamo prima richiamare la procedura di export expdp, impostare: o nome utente e password, oppure con /as sysdba, directory, dumpfile e logfile.

expdp scott/[email protected] directory=DIR_PROVA dumpfile=exp_tipoexport.dmp logfile=exp_tipoexport.logfile

Questa istruzione va sempre dichiarata per tutti i tipi di export quello di:

Export full del database
uno schema intero
dei soli metadati di un intero schema
una o più tabelle

Descriviamo le varie le varie tecniche:

Export full

L’export full del database effettua una copia completa all’interno di uno o, nel caso in cui si attivi il parallelismo, più file.
La prima cosa da verificare sono gli spazi di occupazione, quindi occorre vedere che dimensione ha il database e questo può essere effettuato con il seguente comando:

select sum(bytes/1024/1024) MB from dba_segments;

Vista la dimensione del database verifichiamo se sul FS abbiamo abbastanza spazio. Tenete in considerazione che lo spazio nel database è frammentato e l’export applica la compressione ai dati di default, quindi i dati la dimensione del file sarà ridotta rispetto alla dimensione totale recuperato con la query precedente.

Una volta verificato lo spazio è possibile effettuare l’export con il seguente comando:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_full.dmp logfile=exp_full.log full=y

Nel caso in cui volessi sfruttare il parallelismo e la compressione dati, occorre eseguire il seguente comando:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_full_%U.dmp logfile=exp_full.log full=y parallel=4 compression=ALL

Il parallelismo viene impostato dal carattere %U sulla componente finale del nome e dall’istruzione parallel= numero di parallelismo ossia del numero di file prodotti dall’export.
Il parallelismo va attivato sempre in base al numero di cpu e alla Versione Oracle che deve essere Enterprise Edition.

Export di uno schema intero

L’export di uno schema è la modalità più utilizzata a fronte di richieste di allineamento dati da ambiente di produzione ad ambiente di test o per richieste di migrazione di un determinato o più schema da un database a un altro.

Per verificare la dimensione di uno schema occorre eseguire il seguente comando:

select sum(bytes/1024/1024) MB from dba_segments where owner='PIPPO';

Se fossero più schema:

select sum(bytes/1024/1024) MB from dba_segments where owner in ('PIPPO','PLUTO');

Una volta verificati gli spazi possiamo eseguire l’export con il seguente comando:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_SCHEMA.dmp logfile=exp_full.log schemas=PIPPO

In questo caso ho esportato gli schema PIPPO, PLUTO all’interno del file exp_SCHEMAS.dmp
Se volessi attivare il parallelismo dovrei usare lo stesso comando applicando al nome del file %U.dmp e impostando il parametro parallel=4 come nel seguente comando:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_SCHEMAS_%U.dmp logfile=exp_full.log schema=PIPPO,PLUTO parallel=4

Export dei soli metadati di un intero schema

Se dovessi salvare tutti i metadati di uno schema, ossia solo le strutture delle tabelle e degli indici occorre eseguire il seguente aggiungere la seguente istruzione:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_SCHEMAS.dmp logfile=exp_full.log schema=PIPPO content=METADATA_ONLY

Export di una tabella

L’export di una o più tabelle ha un controllo in più. Oltre a verificare la dimensione che viene effettuato con il seguente comando:

select table_name, bytes/1024/1024 MB from dba_segments where segment_name in ('TAB_PIPPO_1','TAB_PIPPO_2');

Occorre controllare se le tabelle hanno delle referenze con altre tabelle, poichè se così fosse sono da esportare anche le tabelle con la relazione attiva.

set lines 300
spool disable_constraints.sql
select 'alter table '||owner||'.'||table_name||' enable novalidate constraint '||constraint_name||';' from dba_constraints where table_name ='&TABLE';
spool off

Una volta terminato i controlli possiamo eseguire l’export con il seguente comando:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_SCHEMAS.dmp logfile=exp_full.log tables=PIPPO.TAB_PIPPO_1,PIPPO.TAB_PIPPO_2

Trasferimento file dump

Quando effettuiamo l’export dei dati e abbiamo il dump di export a disposizione, dobbiamo trasferirlo nel server in cui è presente l’istanza in cui dobbiamo eseguire l’import.

Il trasferimento può essere effettuato sui sistemi Linux e Unix o con il comando:

scp filedump [email protected]:/path/di/destinazione

O attraverso il protocollo sftp con il seguente comando:

sftp [email protected]
cd /path/di/destinazione
put nomedump

Per i sistemi MS cercare “Esegui” nella ricerca di Cortana e digita:

\\ipserver\c$

Eseguire il login e trasferire il file.

Ora passiamo alla fase di Import

Quando eseguiamo l’import dei dati, oltre ad eseguire i controlli relativi agli spazi dobbiamo verificare altri tipo di controlli che andiamo a verificare.

Import del database

L’import full del database può essere effettuato nel caso in cui l’ambiente di test deve essere ricoperto completamente. In questo caso può essere effettuato l’import full.
L’unico controllo da eseguire è la presenza dei tablespace esattamente come nell’ambiente in cui sono stati esportati. Nel caso un cui i tablespace dovessero essere diversi occorre aggiungere la clausola REMAP_TABLESPACE=OLD_TBSP:NEW_TBSP

Controllare se sono presenti tablespace come in produzione e controllare le relative dimensioni.
Il controllo può essere effettuato attraverso la query riportata nell’articolo Query per vedere le dimensioni di tutte le TABLESPACE del database Oracle – https://www.scriptdba.com/query-per-vedere-le-dimensioni-di-tutte-le-tablespace-del-database-oracle/

Se non ci fosse abbastanza spazio estendere il/i tablespace.

L’import è eseguito con il seguente comando:

impdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_full.dmp logfile=imp_full.log full=y

Eseguire il login e trasferire il file.

impdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_full_%U.dmp logfile=imp_full.log full=y parallel=4

Import di uno schema intero

L’import di uno schema può essere richiesto a fronte di una migrazione di dati da un db a un altro o di un refresh dei dati da ambiente di produzione ad ambiente di test.
In fase di refresh dei dati da ambiente di produzione ad ambiente di test, a meno di richieste di salvataggio di qualche in tabella in particolare, si può eseguire la DROP dello schema con il seguente comando:

drop user PIPPO cascade;

Inoltre va eseguito il controllo degli spazi dei tablespace di destinazione.

Il controllo può essere effettuato attraverso la query riportata nell’articolo Query per vedere le dimensioni di tutte le TABLESPACE del database Oracle – https://www.scriptdba.com/query-per-vedere-le-dimensioni-di-tutte-le-tablespace-del-database-oracle/

Infine puoi eseguire l’import con il seguente comando:

impdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_SCHEMAS.dmp logfile=impd_full.log schema=PIPPO

Import di un set di tabelle

Per eseguire l’import di alcune tabelle occorre avere alcune informazioni da chi ha richiesto l’allineamento.

Occorre verificare se sono presenti contraint attive con la seguente query:

set lines 300
spool disable_constraints.sql
select 'alter table '||owner||'.'||table_name||' disable novalidate constraint '||constraint_name||';' from dba_constraints where table_name ='&TABLE';
spool off

Inoltre se una tabella è già presente, occorre aggiungere la clausola TABLE_EXISTS_ACTION la quale accetta 4 opzioni:
APPEND – Aggiunge i record duplicandoli
REPLACE – Cancella la tabella e la ricrea
SKIP – Salta la tabella e passa all’oggetto successivo
TRUNCATE – Cancella i record della tabella e li reinserisce

Una volta disabilitate le constraint attive, controllato il tablespace in cui è presente la tabella possiamo eseguire l’import con il seguente comando:

expdp "' / as sysdba'" directory=DIR_PROVA dumpfile=exp_SCHEMAS.dmp logfile=exp_full.log tables=PIPPO.TAB_PIPPO_1,PIPPO.TAB_PIPPO_2 TABLE_EXISTS_ACTION=TRUNCATE

Una volta terminato l’importriabilitare le constraint, modificando i comandi inseriti nel file di spool prodotto prima dell’import cambiando l’istruzione disable con enable.

Queste sono le principali modalità di export e import in data pump.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Tuning size Redo Log Oracle

Nell’articolo Tuning size Redo Log Oracle, descrivo la modalità di dimensionamento dei REDO LOG.

I Redo Log sono file dove vengono registrate tutte le operazioni DDL e DML eseguite nel database.
Vengono creati durante la fase di creazione del database e di default vengono creati 3 REDOLOG. Se attivata la funzionalità Multiplexing, i REDOLOG saranno duplicati in diverse posizioni.

Grazie a questi file, insieme agli archive log, abbiamo la possibilità di eseguire il ripristino dei dati esattamente nel momento in cui gli impostiamo il ripristino.

Questi file sono di vitale importanza nel database, proprio per via del ripristino dei dati che Oracle deve essere sempre in grado ripristinare, quindi, nel caso in cui non fosse più possibile aggiornare i REDOLOG, per esempio per problemi di spazio, il database va in crash.

I REDO LOG hanno 3 tipi di stato: ACTIVE, INACTIVE e CURRENT.

Quest’ultimo stato è relativo al file in fase di aggiornamento ossia in fase di scrittura.
Quando raggiunge la dimensione massima, il contenuto viene scritto su un ARCHIVELOG dal processo ARC, il REDOLOG svuotato passa allo stato INACTIVE, il REDOLOG INACTIVE passa allo stato ACTIVE e il REDOLOG ACTIVE passa allo stato CURRENT.

Questo ciclo viene gestito in maniera autonoma da Oracle e i file vengono incrementati in base all’attività del database. Più attività vengono svolte nel DB, più le scritture saranno frequenti.

Se i REDOLOG sono sotto dimensionati rispetto all’attività del database, ci saranno frequenti switch ciclici e questo può causare gravi problemi di performance.

L’unico modo per gestire la frequenza di switch è regolare la dimensione dei file, più aumenta la dimensione, più diminuisce la frequenza.

Ma come possiamo regolare la corretta frequenza?

Tuning size Redo Log Oracle

Secondo il documento ufficiale Oracle General Guideline For Sizing The Online Redo Log Files (Doc ID 781999.1), non c’è una linea ben definita per la dimensione, poichè non tutti gli ambienti hanno la stessa configurazione.

Indicativamente bisogna impostare 1 switch ogni 20 minuti ossia intorno ai 5 switch l’ora.

Quindi come prima operazione dobbiamo individuare quanti switch vengono effettuati in media, e questo può essere effettuato dalla query riportata nell’articolo Query REDO LOG numero switch

Se vediamo uno switch eccessivo dobbiamo aumentare la dimensione dei REDO LOG.

Quest’operazione va effettuata in un momento di basso carico del database, poichè i frequenti switch non vi permetterebbero di operare sul singolo REDO LOG.

Quindi per individuare il momento in cui il DB produce meno archive è possibile attraverso la query utilizzata in precedenza dell’articolo Query REDO LOG numero switch.

Quando l’attività di switch è minore possiamo procedere.

Con la query dell’articolo Query REDO LOG nome file e status, recuperiamo nome, dimensione e status dei REDO LOG come il seguente output:

 GROUP# MEMBER                              STATUS                  Size MB
------- ----------------------------------- -------------------- ----------
      1 /dati/XE/redo01.log                 CURRENT                     200
      2 /dati/XE/redo02.log                 INACTIVE                    200
      3 /dati/XE/redo03.log                 ACTIVE                      200

In questo caso partiamo dal REDO LOG con STATUS INACTIVE.

Quindi eseguiamo il seguente comando:

 alter database add logfile group 4 '/dati/XE/redo04.log' size 300M;
 alter database add logfile group 5 '/dati/XE/redo05.log' size 300M;
 alter database add logfile group 6 '/dati/XE/redo06.log' size 300M;

Successivamente dobbiamo eliminare i precedenti REDO LOG, ma prima dobbiamo eseguire lo switch del REDO LOG CURRENT verso i nuovi REDO.

Questo avviene attraverso il seguente comando:

alter system checkpoint;
alter system switch logfile;

Controlliamo se lo stato CURRENT è passato ai nuovi REDO LOG.

Successivamente eseguiamo la DROP dei REDO LOG con la precedente dimensione con il seguente comando:

alter database drop logfile group 1;
alter database drop logfile group 2;
alter database drop logfile group 3;

Per qualsiasi dubbio non esitate a commentare l’articolo.

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

SQL Server cambio path database di sistema

Nell’articolo SQL Server cambio path database di sistema, descrivo un attività che ho dovuto affrontare per un cliente.

In notturna, durante il turno in reperibilità, sono stato svegliato per un allarme sugli spazi dei file di dati dei database di sistema dell’istanza SQL Server.

Il tempo di collegarmi, controllo e l’allarme era rientrato in maniera autonoma. Poco male. Chiuso il ticket e tornato a dormire.

Arrivano le 7 di mattina e si ripresenta la stessa situazione. Mi collego, controllo, allarme sparito.
Questa volta però approfondisco l’analisi e capisco subito la causa del problema.

Controllando mi sono accorto che i database sono stati creati sul disco C:\ rispetto al disco dedicato S:\. Oltretutto la dimensione del disco C:\ era malconcia e molto probabilmente gli allarmi sono stati causati dalla dimensione dinamica del page file del sistema operativo.

Quindi ho deciso di spostare i file di dati e dei TLog nella corretta posizione, secondo lo standard aziendale e ho deciso di indicare i passi eseguiti in questo articolo.

L’obbiettivo del tutorial è indicare la modalità per eseguire il cambio path dei file di dati e dei Transaction Log dei database di sistema.

L’attività sembra complicata ma seguendo i seguenti passi sarà più semplice di quanto si pensa.

Come prima operazione cambiamo le informazioni relative alla posizione dei file di dati e dei TLog dei database model e msdb sul database master come indicato di seguito:

USE master
Go
ALTER DATABASE model MODIFY FILE ( NAME = 'modeldev' , FILENAME = 'S:\XXXX_Dati_01\Data\model.mdf' );
Go
ALTER DATABASE model MODIFY FILE ( NAME = 'modellog' , FILENAME = 'S:\XXXX_Log_01\TLog\modellog.ldf' );
Go
ALTER DATABASE msdb MODIFY FILE ( NAME = 'MSDBData' , FILENAME = 'S:\XXXX_Dati_01\Data\MSDBData.mdf' );
Go
ALTER DATABASE msdb MODIFY FILE ( NAME = 'MSDBLog' , FILENAME = 'S:\XXXX_Log_01\TLog\MSDBLog.ldf' );
Go

Una volta terminato procediamo con lo stop dell’istanza attraverso lo stop del servizio SQLServer.
L’operazione può essere eseguita sia dalla finestra dei servizi o dal CMD di windows con il seguente comando:

net stop mssqlserver

Successivamente eseguiamo la copia dei file di dati e dei TLog sulla posizione indicata nei comandi precedenti.
Infine eseguiamo lo start dell’istanza per verificare il corretto posizionamento dei file di sistema appena spostati con il seguente comando:

net start mssqlserver

Ok. I database msdb e model sono stati migrati sul disco dedicato.

Adesso passiamo al database master.

SQL Server cambio path database di sistema

Lo spostamento del database master ha una procedura diversa rispetto agli altri 2 database di sistema.

Andiamo sul menù start di Windows Server, apriamo il Configuration Manager di SQL Server e seguiamo i seguenti passi:

SQL Server Configuration Manager > Destro del mouse sull’istanza SQL Server > Apriamo le proprietà come da seguente immagine:

Scheda Startup Parameters e settare i nuovi parametri editando “Specify a startup parameter” con i nuovi path, comprensivi del nome dei file.


L’unica attenzione a mettere -d attaccato al path dei dati e -l attaccato al path dei TLog.
Per fissare il parametro click su Update e sul bottone Applica.

A questo punto possiamo fermare l’istanza o dai servizi o dal seguente comando:

net stop mssqlserver

Copiare il file di dati e il Transaction Log del database master sulla directory di destinazione.

Una volta terminata la copia possiamo avviare l’istanza o dalla finestra dei servizi o dal CMD di Windows con il seguenti comando:

net start mssqlserver

Se è stato fatto tutto correttamente l’istanza si aprirà senza presentare errori.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Solaris 11 Oracle RAC 12 Tuning SGA

Nell’articolo Solaris 11 Oracle RAC 12 Tuning SGA, descrivo una situazione di tuning che ho dovuto affrontare per un cliente.

Il tuning è stato applicato su un database Oracle RAC 12.1 a 2 nodi Oracle Solaris 11, da qui sono partiti i miei studi che ho deciso di condividere.

Dalla versione 10g del database Oracle, le aree di memoria vengono gestite in maniera automatica.

Questo avviene attraverso 2 principali architetture:

ASMM Automatic Storage Memory Management, che prevedere la gestione automatica delle aree interne alla SGA (DB_CACHE_SIZE, SHARED_POOL_SIZE, JAVA_POOL_SIZE, LARGE_POOL_SIZE, ecc..) applicabile attraverso la popolazione dei parametri sga_target, sga_max_size e pga_aggregate_target nell’spfile.

Dalla versione 11:
AMM Automatic Memory Management, che prevede la gestione dinamica della SGA e della PGA, applicabile attraverso i parametri memory_target e memory_max_target nel spfile.

Quest’ultima funzionalità, sul totale di memoria che viene assegnata al parametro memory_target, utilizza il 60% per la SGA e il 40% per la PGA e questo, in database di grandi dimensioni, non permetterebbe il completo utilizzo della RAM assegnata.

Proprio per questo motivo l’architettura AMM è sconsigliata per database con SGA di grandi dimensioni.

Inoltre, quando il parametro memory_max_target per l’architettura AMM o il parametro sga_max_size per l’architettura ASMM sono maggiori rispetto ai relativi parametri memory_target e sga_target, è possibile estendere la SGA a caldo fino alla size massima impostata.

Per utilizzare questa funzionalità, l’OS Solaris deve avere abilitata la funzionalità OSM Optimized Shared Memory, il quale permette la resize dinamica senza dover riavviare l’istanza.

Per controllare se l’OMS è abilitato occorre eseguire il seguente comando:

ipcs -dm

L’OSM è abilitato se sulla colonna ALLOC è presente un numero intero.
Se dovesse essere presente un – vuol dire che non l’OSM non è attivo.

OSM vs DISM vs ISM

Come indicato nel documento Administering Oracle Database on Oracle Solaris, Oracle Database automaticamente usa OSM se lo trova disponibile.

Se OSM non è disponibile, Oracle Database utilizza automaticamente o DISM Dynamic Intimate Shared Memory o ISM Intimate Shared Memory in base a come viene impostato il parametro SGA_MAX_SIZE.

Di seguito i criteri di abilitazione:

Oracle Database utilizza DISM se è disponibile sul sistema e se il valore del parametro SGA_MAX_SIZE è maggiore della dimensione del parametro SGA_TARGET. Ciò consente a Oracle Database di bloccare solo la quantità di memoria fisica utilizzata.

Oracle Database utilizza ISM se il valore del parametro SGA_MAX_SIZE è uguale o inferiore alla dimensione del parametro SGA_TARGET.

Quindi per accertarci quale funzione di gestione memoria condivisa sia utilizzata, possiamo individuarla con il comando pmap del processo smon del database.

Individuiamo il PID del processo di backgruond del database SMON con il seguente comando:

ps -ef |grep smon

Con pmap verifichiamo il PID dell’SMON con il seguente comando (sostituire <PID> con il PID ricavato dal precedente comando):

pmap –xs | grep ism

Apprese queste informazioni decido di utilizzare l’architettura ASMM utilizzando OSM.

Inoltre per estendere i parametri di memoria, occorre controllare il parametro project.max-shm-memory, che sia superiore alla dimensione massima dei parametri di SGA e PGA, in tutti i nodi che compongono il RAC.
Se il valore dovesse essere inferiore, la fase di allocazione dei parametri fallirebbe con l’errore ORA-27125.

Una volta verificati i valori dell’OS e individuata l’architettura da applicare, passiamo all’estensione della SGA.

Solaris 11 Oracle RAC 12 Tuning SGA

Nel mio caso avevo in utilizzo l’architettura AMM, ma devo portare la SGA a 20G e PGA 5G, quindi per ottimizzare l’utilizzo della memoria ho deciso di utilizzare i parametri ASMM, quindi configuro i parametri sga_target=20G, sga_max_size=25G e pga_aggregate_target=6G.

Prima di effettuare qualsiasi modifica, salvare il pfile di tutte le istanze del RAC.

create pfile='/tmp/pfile.ora' from spfile;

Una volta salvato il pfile, procediamo con la disabilitazione dell’AMM Automatic Memory Management con i seguenti comandi:

alter system reset memory_max_target scope=spfile SID='*';
alter system reset memory_target scope=spfile SID='*';

Abilitiamo ASMM Automatic Storage Memory Management

alter system set SGA_MAX_SIZE=25G scope=spfile SID='*';
alter system set SGA_TARGET=20G scope=spfile SID='*';
alter system set PGA_AGGREGATE_TARGET=6G scope=spfile SID='*';
alter system set pga_aggregate_limit=10g scope=spfile SID='*';

Una volta configurati i parametri, riavvio le istanze con il seguente comando:

srvctl stop database -d TEST -o immediate
srvctl start database -d TEST

E il gioco è fatto.

Se incontrate problemi potete consultare il tutorial Tuning SGA Oracle database, dove viene indicato lo startup e ripistino del spfile, dal pfile salvato in precedenza.

Se volete approfondire con i tutorial ufficiali Oracle dedicati all’argomento di seguito riporto i vari articoli:

Administering Oracle Database on Oracle Solaris
Tuning Oracle Database
Requirements for Installing Oracle Database 12.1 on Solaris 11 SPARC/ x86-64 (Doc ID 1525614.1)
Kernel setup for Solaris 10 and Solaris 11 using project files (Doc ID 429191.1)
Dynamic SGA Tuning of Oracle Database on Oracle Solaris with DISM

Per visionare i miei tutorial Oracle clicca qui!
A questo LINK, invece, troverai le query SQL.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Tuning SGA Oracle database

Con l’articolo Tuning SGA Oracle database, descrivo le funzionalità della SGA del database Oracle creata.

La SGA del database Oracle è l’area di memoria RAM che viene utilizzata dal database Oracle e allocata in fase di startup. Più nello specifico viene allocata in fase di startup nomount.

Quando viene eseguito il comando startup, Oracle legge le informazioni presenti sul spfile.
Se trova congruenza con l’ambiente in cui viene startato, ossia, se l’ambiente soddisfa i parametri indicati nell’spfile, l’istanza allocherà la memoria completando la fase di startup nomount.

Le aree di MEMORIA della SGA

La SGA all’interno ha altre areee di memoria, ogniuna con la propria funzione.

Le principali areee di memoria sono:

SHARED POOL – Area dedicata alle librerie delle query
BUFFER CACHE – Area dedicata al caricamento di dati in memoria acceduti di frequenza
REDO BUFFER – Area dedicata alla scrittura dei REDO LOG
JAVA POOL – Area dedicata al processamento dei dati JAVA
ecc…

Queste aree di memoria possono essere gestite in maniera automatica da Oracle.

Se volessi disabilitare la gestione automatica delle aree di memoria interne alla SGA, occorre specificare le dimensioni delle varie memorie aree di memoria sull’spfile.

A quel punto la gestione non sarebbe più dinamica, poichè con le dimensioni fissate.

La modalità di gestione automatica delle aree interne alla SGA , si chiama ASMM Automatic Shared Memory Management ed è stata introdotta in Oracle 10g, applicabile attraverso i parametri sga_target, sga_max_size, pga_aggregate e l’azzeramento delle altre aree di memoria.

AMM vs ASMM

Inoltre dalla versione Oracle 11g, è stata implementata un ulteriore modalità di gestione della memoria automatica estesa alla dimensione della SGA e della PGA.

Questa modalità viene chiamata AMM Automatic Memory Management e viene attivata popolando i parametri memory_target e memory_max_target ed eliminando dall’spfile i parametri sga_target, sga_max_size, pga_aggregate:

Tuning SGA Oracle database

Comandi per abilitare AMM

alter system set  memory_max_target=4G scope=spfile;
alter system set memory_target=3G scope=spfile;

Comandi per disabilitare ASMM:

alter system reset sga_max_size scope=spfile;
alter system reset sga_target scope=spfile;

Controllate sempre le note ufficiali Oracle database e note ufficiali OS, in base al sistema operativo che ospita il database.

L’AMM è la modalità attuale consigliata da Oracle, tuttavia, in database con SGA superiore ai 4G, Oracle consiglia di abilitare la funzionalità LARGE PAGE, indipendentemente dal sistema operativo.

ENABLE LARGE PAGE

Questo perchè la memoria RAM di default viene allocata con pin da 4k, e nel caso in cui la SGA avesse una dimensione pari a 15G, il sistema operativo sarebbe costretto ad utilizzare miliardi di pin da 4k fino a comporre la dimensione di 15G.

Questo può mettere il sistema operativo in difficoltà o comunque sia non al massimo delle performance.

Vantaggi LARGE PAGE

Inoltre, se il LARGE PAGE è abilitato la SGA occuperà la memoria RAM allocando pin da 2M e questo consentirebbe al sistema operativo di gestire milioni di pin e non più miliardi di pin.

L’abilitazione della funzionalità Large Page, è altamente consigliata per via dei netti miglioramenti sulle performance e stabilità del database.

Ogni sistema operativo, ha le proprie particolarità per abilitare questa funzione.

Consigli

Quindi, il consiglio che posso darvi, cercare sempre online la documentazione ufficiale del sistema operativo e del database in cui dovete effettuare questo tipo di modifiche.
Verificare la modalità di abilitazione Large Page e Tuning SGA, ma sopratutto, prima di effettaure qualsiasi modifica, salvate sempre l’spfile con il seguente comando:

Salvataggio dell’SPFILE con la creazione del PFILE

create pfile='/tmp/pfile.ora' from spfile;

Nel caso in cui vi dovesse andare male la modifica e il db non si apre, è possibile tornare ai parametri iniziali con il PFILE salvato in precedenza.

La sequenza dei comandi è la seguente:

sqlplus / as sysdba
startup pfile='/tmp/pfile.ora'
create spfile from pfile='/tmp/pfile.ora'

Con questi comandi il database si aprirà con i parametri antecedenti la modifica.

Nel caso di un RAC, le operazioni sono le stesse. Occorre eseguire lo start del database in maniera manuale, ricreare l’spfile, chiudere il database ed eseguire lo start con i comandi del CRS, reperibili nella pagina srvctl start database.

Per visionare i miei tutorial Oracle clicca qui!
A questo LINK, invece, troverai le query SQL.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Architettura Multitenant Database Oracle

L’Architettura Multitenant Database Oracle è progettata per ospitare più database PDB “PLUGGABLE DATABASE” all’interno di un’unica istanza contenitore CDB “CONTAINER DATABASE”.
L’archittttura dell’istanza CDB al suo interno mantiene piu’ PDB usufruendo del medesimo set di processi e della stessa SGA (System Global Area).
Invece per i componenti di sistema (control file, redo log, spfile, …) sono pertinenti al solo CDB.

La creazione di un’utenza e’ locale al DB a cui si e’ connessi, ma e’ ammissibile realizzare nel CDB utenze generali per tutti i PDB.

In un PDB è consentita la creazione di tablespace temporanei, ma se non viene fatto viene utilizzato il tablespace temporaneo del CDB.

Infine i datafile sono raccolti in una directory con nome uguale al nome del PDB e possono utilizzare la modalita’ OMF (Oracle Managed Files).
La creazione di database collegabili, lo spostamento di database collegabili fra contenitori e la clonazione di database collegabili vengono eseguiti con comandi SQL e queste operazioni vengono eseguite solo in pochi secondi.
L’avvio di un CDB avviene come quello di una normale istanza con il comando di startup da SQL*Plus.
I PDB vanno invece aperti con un comando di OPEN, differentemente al CDB, di default sono in stato MOUNTED e dunque non accessibili.
Possiamo anche creare anche il nostro PLUGGABLE database in fase di installazione del database. Di seguito creeremo un PDB con un db già installato.

Creare ed aprire un PDB Database:

Come prima cosa creeremo il nostro PLUGGABLE DATABASE di nome PDB1 con il seguente comando:

CREATE PLUGGABLE DATABASE pdb1;

Ora possiamo accedere al nostro PDB con il seguente comando:

ALTER SESSION SET CONTAINER=pdb1;

I PDB appena creati sono in stato MOUNT e vengono aperti come tutte le normali istanze Oracle con il seguente comando:

ALTER PLUGGABLE DATABASE PDB1 OPEN;

Architettura Multitenant Database Oracle

Creare utenze locali e comuni

Gli utenti creati su un PDB sono e restano locali al PDB:

CREATE USER PIPPO IDENTIFIED BY xxx;

Invece gli utenti creati con il prefisso c## sono comuni a tutti i PDB e CDB:

CREATE USER C##PIPPO IDENTIFIED BY xxx all;

Collegarsi al CDB ed i PDB

Per connettersi ad un PDB o al CDB sono disponibili tre alternative:

1.Con la variabile di sessione container:

AlTER SESSION SET CONTAINER=pdb1;
ATER SESSION SET CONTAINER=cdb$root;

2.Utilizzare un servizio sul listener:

conn sys/[email protected] as sysdba;

3.Utilizzare la variabile d’ambiente TWO TASK:

export TWO_TASK=PDB1;
sqlplus / as sysdba;

Come capire dove si è connessi:

Sembra banale ma le prime volte non è facile capire dove si è connessi, il seguente comando mostrerà il database in cui ci siamo:

show con_name;

Come controllare il nome del CONTAINER e PLUGGABLE database:

select name from V$CONTAINERS;

Controllare i nomi dei PLUGGABLE database:

select pdb_name, status from DBA_PDBS order by 1;

Attivare un modo automatico i PDB:

Nota bene lanciare i seguenti comandi da fuori il PDB quindi dentro il nostro CONTAINER:

ALTER PLUGGABLE DATABASE pdb1 OPEN;
ALTER PLUGGABLE DATABASE pdb1 SAVE STATE;

Cancellare un PDB

La cancellazione dell’esempio rimuove definitivamente e completamente il PDB ed i suoi datafile.

DROP PLUGGABLE DATABASE pdb1 INCLUDING DATAFILES;

Assegniamo i ruoli e privilegi

GRANT CREATE TABLESPACE TO PIPPO;
GRANT CONNECT TO PIPPO;
GRANT CREATE TABLE TO PIPPO;
GRANT CREATE ANY DIRECTORY TO PIPPO;

Per visionare i miei tutorial Oracle clicca qui!
A questo LINK, invece, troverai le query SQL.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Comandi Linux di base

Query recuperare spazio allocato dai DATAFILE

Nell’articolo Comandi Linux di base, riporto i principali comandi che vi permetteranno di gestire il sistema operativo più utilizzato in ambienti Enterprise senza troppe difficoltà.

Il sistema operativo Linux in versione server, nella maggior parte dei casi, viene gestito unicamente da riga di comando.
Se non si conoscono i numerosi comandi, lavorare diventa molto difficile.

Quindi di seguito riporto la lista dei principali comandi:

Comandi Linux di base

Gestione directory

cd <nome_directory> = Comando per entrare in una directory
cd .. = Tornare indietro di una directory
cd ../.. = Tornare indietro di 2 directory
cd = Vai nella home dell’utente con cui sei collegato
rmdir <directory> = Cancella la directory soltanto se non sono presenti file
pwd = Vedi il path in cui ti trovi
mkdir = Crea una directory
mkdir -p /path/da/creare = Crea tutto il path con un comando
mkfs.ext4 = Formatta una partizione in ext4

Gestione file

ls = Comando list. Mostra i file della directory in cui ti trovi
ls -ltr = Mostra i file con i relativi permessi e proprietario, data ultimo aggiornamento e dimensione dei file presenti su una directory
ls -ltra = Mostra i file nascosti con le caratteristiche del comando precedente
cp pippo pluto = Copia il file pippo con il file pluto
mv pippo /tmp = Muove il file nella directory /tmp
rm -f pippo = Rimuove i file pippo
rm -fr <directory> = Cancella la directory e i file all’interno
cat = Visualizza un file completo
grep = Cerca la parola
cat pippo |grep ciao = cerca nel file pippo tutte le righe con la parola ciao
head -50 = Visualizza le prime 50 righe di un file
tail -50f = Visualizza le ultime 50 righe e vedi il log in diretta
touch <nome_file> = Crei file
./<nome file> = Esecuzione di uno script

Gestione utenze

adduser = Crea un utente
addgroup = Crea un gruppo
passwd = Cambio password
passwd oracle = Eseguito da root cambiamo la password dell’utente Oracle
su – = Diventi utente root
su – oracle = Diventi utente oracle
sudo su – oracle = Diventi utente oracle se fa parte degli utenti sudoers

Gestione permessi e proprietario

chown oracle:dba <nome_file> = Cambia il proprietario e il gruppo in oracle dba di un file
chmod 777 <nome_file> = Assegna il massimo dei permessi a un file

Comandi di rete

ping = Contatta un ip o un nome host
ip addr = Visualizza dettagli interfacce di rete
scp pippo [email protected]:/home/oracle = Copia il file pippo con l’utente oracle nel server remoto depositando il file nel path /home/oracle
sftp 192.168.3.10 = Collegamento in sftp per trasferire da un server ad un altro con i comandi get e put
ssh 192.168.3.10 = Collegamento in ssh ad un server Linux o Unix

Controllo processi e risorse

top = Monitoraggio processi e risorse
ps -ef = Elenco processi
ps -ef |grep oracle |grep LOCAL=NO = Elenco processi utente di sistema oracle e processi relativi a sessioni applicative
kill -9 <Processi ID> = Esegue il kill del processo indicato

Gestione File System

df -k = Mostra le dimensioni in KB dei File System
df -h = Mostra le dimensioni in GB dei File System
du -ks * = Mostra le directory con le relative dimensioni in KB

Se avete qualche dubbio o volete aggiungere qualche comando alla lista contattatemi in privato. Sarò felice di darvi supporto.

Per visionare le mie guide sui Comandi CRS clicca qui!
A questo LINK, invece, troverai le query SQL

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Centos configurazione IP statico

Con l’articolo Centos configurazione IP statico, vi presento il modo corretto di impostare la scheda di rete per potersi connettere con Linux attraverso il protocollo ssh.

Il sistema operativo Linux, di default imposta l’IP acquisito attraverso il DHCP Dynamic Host Configuration Protocol, ossia aquisice in maniera automatica un IP dinamico, quindi può cambiare a ogni riavvio della macchina.

Per installare un qualsiasi software che ha bisogno di un IP statico da cui poter essere raggiungibile, occorre effettuare qualche modifica a livello OS, quindi vediamo di seguito come fare.

Andiamo sul path /etc/sysconfig/network-script con il seguente comando:

cd /etc/sysconfig/network-script

Se abbiamo appena installato Linux Centos seguendo la guida Installazione Centos 7 su VirtualBox, avremo 2 interfacce di rete:
l’interfaccia ifcfg-enp0s3 la quale indica l’indirizzo IP reperito dalla scheda NAT e l’interfaccia ifcfg-enp0s8 la quale indica l’indirizzo IP reperito dalla scheda solo host ossia dall’Adapter di rete.

Centos configurazione IP statico

A questo punto dobbiamo prendere la maschera dichiarata nell’Adapter di rete creato in precedenza, nel nostro caso 192.168.10. e impostare i parametri del file ifcfg-enp0s8, quindi apriamo il file con il seguente comando:

vi ifcfg-enp0s8

Modifichiamo i seguenti parametri BOOTPROTO come segue:

BOOTPROTO=static
IPV6INIT=no
IPV6_AUTOCONF=no

Eliminare con dd le restanti righe relative a IPV6 e aggiungiamo le seguenti righe:

IPADDR=192.168.10.10 
NETMASK=255.255.255.0
GATEWAY=192.168.10.1

Cambiare ONBOOT=yes e riavviamo la macchina con il comando:

reboot

Una volta che la macchina torna disponibile eseguiamo il login e verifichiamo se abbiamo acquisito correttamente l’indirizzo IP con il comando:

ip addr

Per visionare i miei tutorial Oracle clicca qui!
A questo LINK, invece, troverai le query SQL.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Per qualsiasi dubbio non esitate a commentare l’articolo.

Installazione Centos 7 su VirtualBox

Nell’articolo Installazione Centos 7 su VirtualBox mostreremo come avere un piccolo server Linux in locale sul proprio PC. Questa guida è perfetta per avere un ambiente di test dove poter testare i vari software e le diverse architetture.

Linux Centos 7 è un sistema operativo Open Source con Kernel che si basa su rpm, quindi completamente compatibile con OS Red Hat, Oracle Linux e Fedora, anche se quest’ultimo non è molto utilizzato per ambienti server, ma principalmente richiesto per ambienti Desktop.

Per poter installare Linux Centos 7 su VirtualBox, occorre prima scaricare il software VirtualBox e installarlo sul sistema operativo che utilizziamo sul PC fisico.

Il software VirtualBox è reperibile al seguente link.

Successivamente scarichiamo la iso di Linux Centos 7 dal seguente link.

Come prerequisiti di sistema consiglio un PC con minimo 8GB di RAM, con meno RAM le performance potrebbero cambiare drasticamente.

A questo punto configuriamo la macchina virtuale con 2 CPU, 4G di RAM, 2 schede di rete 1 NAT e l’altra scheda con bridge. Per far comunicare correttamente il PC fisico con il PC virtuale creeremo un Adapter di rete da VirtualBox.

Vediamo step by step la configurazione della macchina virtuale con VIrtualBox.

Configurazione Hardware virtuale

Lanciamo l’eseguibile e clicchiamo su Nuova:

Successivamente impostiamo il nome della macchina, la posizione del file VDI dove sarà installato il sistema virtuale e la tipologia di sistema operativo che andrà ad ospitare.

Impostiamo 4G di RAM ossia 4096MB:

Lasciamo l’impostazione di default Crea subito un disco fisso virtuale e click su Crea:

Lasciamo impostazione VDI e click su Successivo:

Allocato dinamicamente e click su Successivo:

Impostiamo la posizione e la dimensione di 50G del file VDI e click su Crea:

Ora passiamo alla configurazione delle CPU cliccando su Sistema:

Clicchiamo sulla scheda Processore e impostiamo 2 CPU come da seguente immagine:

Passiamo alla configurazione della rete che vedrà due schede: NAT e Scheda solo host, ma prima creeremo un adapter di rete che ci permetterà di mettere in comunicazione il PC fisico con il PC virtuale.

Clicchiamo su File e su Gestore di rete dell’host:

Clicchiamo su Crea

Successivamente vedremo il nostro Adapter di rete. Disabilitiamo il server dhcp e impostiamo l’indirizzo IP 192.168.10.1 come da seguente immagine:

In questo modo il nostro PC fisico avrà acquisito una nuova scheda di rete con un IP che inizia con il suffisso 192.168.10 e un numero finale che varia tra il 2 e il 255. La stessa cosa avverrà nella macchina virtuale e questo permetterà la comunicazione tra le 2 macchine.

Adesso possiamo configurare le Schede di rete cliccando su Rete:

Sulla scheda 1 è presente la configurazione della scheda di rete NAT. Lasciamo la configurazione invariata:

Sulla scheda 2 impostamo la Scheda solo host come da immagine:

Infine è rimasto che andare sulla sezione Archiviazione per caricare il file iso sul lettore CD virtuale cliccando sull’icona del CD del Controller IDE e cliccare sull’icona del CD in alto a destra dell’immagine e puntiamo al file iso come da seguente immagine:

Installazione Centos 7 su VirtualBox

Finalmente abbiamo terminato la configurazione dell’Hardware della macchina virtuale. Ora possiamo avviarla e se tutto è stato configurato correttamente potremo cliccare su Install CentOS 7

In ambienti server troveremo solo sistemi con lingua inglese, ergo lasceremo la configurazione del nostro sistema operativo in lingua inglese e clicchiamo su Continua:

Come prima settaggio, impostiamo il paese e il fuso orario pertinente e clicchiamo su Done:

Successivamente impostiamo la tastiera Italiana ed eliminiamo la tastiera inglese.
Il risultato sarà come la seguente immagine:

Passiamo alla configurazione dello storage. Clicchiamo su I will configure partitioning e clicchiamo su Done.

Clicchiamo inizialmente su Click here to create them automatically e successivamente passiamo alla configurazione dei FS. Riduciamo la dimensione della FS / a 40G e click su Update Settings come da seguente immagine:

Aumentiamo l’area di swap a 4G come da seguente immagine:

Con il tasto + creiamo un FS con label /home come da seguente immagine e impostiamo la dimensione di 5G:

Se avremo la configurazione come la seguente immagine clicchiamo su Done e su Add mount point:

Infine attiviamo le schede di rete e diamo il nome alla macchina virtuale come di seguito dettagliato:

A questo punto possiamo far partire l’installazione cliccando su Begin installation:

Come ultimo step prima di avere il sistema operativo a nostra disposizione, impostiamo la password di root come da seguente immagine:

Alla fine dell’installazione clicchiamo su Reboot come da seguente immagine:

A questo punto abbiamo il nostro sistema Linux a disposizione.

Per avere una corretta configurazione della rete, in modo che ci permetta di connetterci alla macchina attraverso il protocollo ssh, passiamo all’articolo Centos configurazione IP Statico

Per visionare i miei tutorial Oracle clicca qui!
A questo LINK, invece, troverai le query SQL.

Resta aggiornato sulle nostre attività entrando a far parte della nostra community:
Facebook
Youtube
Linkedin

Per qualsiasi dubbio non esitate a commentare l’articolo.

Wordpress Social Share Plugin powered by Ultimatelysocial