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

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

EXPORT ORACLE in DATAPUMP

L’EXPORT ORACLE in DATAPUMP viene usato quando migriamo un database, per via di un ipotetico cambio di release o di un ambiente server, o semplicemente per un allineamento dati da ambiente di produzione a collaudo.

Lo spostamento dati viene eseguito attraverso il tool exp e imp.
Dalla versione Oracle 10g, è stato introdotto export e import in datapump, expdp e impdp.
Questo tool oltre ad essere più performante in termini di tempistiche, sono state introdotte nuove modalità per effettuare lo spostamento dei dati.

Il comando per verificare i parametri da impostare è il seguente:

exp help=yes

expdp help=yes

Esempio di EXPORT ORACLE in DATAPUMP

Per prima cosa guardo quanto pesa l’utente:

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

Controllo quanto pesa lo schema per vedere se c’è spazio nel server

df -k

Creo la directory d’appoggio su un FS del sistema operativo dove c’è spazio free:

mkdir /dbTEST/export

Registro la directory nel database creata in precedenza nel sistema operativo in modo che Oracle possa leggere e scrivere nella directory del sistema operativo:

create or replace directory EXPDIR AS '/dbTEST/export';

Eseguo il comando di export datapump per eseguire l’export dello schema SH, il quale sarà esportato nel file dump exp_SH.dmp.
I dettagli dell’export saranno scritti sul file di log exp_SH.log e il file sarà reperibile nella directory EXPDIR ossia /dbTEST/export.

expdp "'/ as sysdba'" directory=EXPDIR dumpfile=exp_SH.dmp logfile=exp_SH.log SCHEMAS=SH

EXPORT DI SPECIFICHE TABELLE DI UNO SCHEMA

Ci potrebbe capitare di dover esportare solo qualche tabella di un determinato schema. Il controllo che dobbiamo fare e quello di verificare se le tabelle che saranno oggetto di export hanno qualche referenza con altre tabelle. Nel caso in cui fossero tabelle referenziate occorrerà esportare tutte le tabelle collegate tra loro.

Di seguito il comando di export delle tabelle ORDERS, INVENTORIES, CUSTOMERS, PROMOTIONS dello schema OE. I dati saranno esportati nel file dump exp_tab_OE.dmp, i dettagli dell’export saranno scritti nel file di log exp_tab_OE.log e i file saranno recuperabili nella directory EXPDIR ossia /dbTEST/export.

expdp "'/ as sysdba'" directory=EXPDIR dumpfile=exp_tab_OE.dmp logfile=exp_tab_OE.log TABLES=OE.ORDERS,OE.INVENTORIES,OE.CUSTOMERS,OE.PROMOTIONS

Se invece volessimo effettuare un export completo del database occorrerà eseguire un export full eseguibile con il seguente comando:

expdp "'/ as sysdba'" directory=POLPY dumpfile=exp_tab_OE.dmp logfile=full

Se avete dubbi non esitate a scrivere sui commenti.

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

Oracle RESTORE POINT FLASHBACK

Con l’articolo Oracle RESTORE POINT FLASHBACK, vi mostrerò come ripristinare il database, attraverso la creazione di uno o più RESTORE POINT da applicare in caso di rollback su attività andate male.

Per un cliente che ha dovuto applicare aggiornamenti sull’applicazione e sulla modifica delle strutture dati sul database Oracle dovevamo salvare i dati prima di questa attività invasiva.

Oracle offre diverse soluzioni per salvare i dati. E’ possibile effettuare un backup e successiva restore con duplicate, soluzione efficace ma sicuramente troppo onerosa in termini di tempo.

Un’altra soluzione valida è effettuare il salvataggio dei dati a livello logico, quindi con il tool export / import in datapump.
Eseguire l’export di uno schema prima di svolgere l’attività, può essere una soluzuine valida.
I dati e i metadati saranno salvati su un file dump esterno al database scaricato su File System del sistema operativo.
Il ripristino avverrebbe con la cancellazione dello schema esistente e impdp dello schema salvato in precedenza con l’export.
Come detto prima, anche la modalità di export e import in datapump è molto efficace, ma non la più veloce sul ripristino.

La soluzione più veloce nel ripristino di un database è la creazione di un RESTORE POINT prima di effettuare particolari modifiche.

A fronte di un attività che implica un fermo applicativo e occorre salvare i dati in via preventiva, bisogna creare un RESTORE POINT con il seguente comando:

Oracle RESTORE POINT FLASHBACK

CREATE RESTORE POINT "NOME_RESTORE_POINT" GUARANTEE FLASHBACK DATABASE;

A questo punto il RESTORE POINT è stato creato, il quale è possibile controllare la sua presenza con la seguente query:

col name for a40
col time for a50
set linesize 200
select NAME,SCN,TIME from v$restore_point;

Se l’attività di aggiornamento è terminata con successo, sarà possibile eliminare il restore point con il seguente comando:

DROP RESTORE POINT "NOME_RESTORE_POINT";

Non scordatevi di cancellarlo, poichè lasciandolo aperto saturerete la flash_recovery_area.

Nel caso in cui l’attività é andata male, e dovete ripristinare il sistema al momento in cui è stato creato il restore point occorre chiudere completamente il database e successiva apertura in mount con i seguenti comandi:

shutdown immediate
startup mount

Nel caso in cui fosse un RAC, eseguire lo startup di una sola istanza con l’articolo srvctl start instance e per ripristinare il database eseguire il seguente comando:

FLASHBACK DATABASE TO RESTORE POINT "NOME_RESTORE_POINT";

Infine per rendere il database disponibile eseguire la open resetelogs con il seguente comando:

ALTER DATABASE OPEN RESETELOGS;

Nel caso in cui fosse un RAC, una volta aperta la prima istanza, è possibile startare tutte le altre istanze del RAC.

A questo punto, il database sarà tornato allo stato in cui è stato genereto il RESTORE POINT.

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

Installazione Oracle 19 su Oracle Linux 8 in VirtualBox 6

Nell’articolo Installazione Oracle 19 su Oracle Linux 8 in VirtualBox 6 vi mostrerò come installare il nuovo database Oracle 19 sul sistema operativo Oracle Linux 8, sulla piattaforma VirtualBox 6.0.

Installazione Oracle 19 su Oracle Linux 8 in VirtualBox 6
REDWOOD CITY, CA/USA – MAY 31, 2014: Oracle corporate headquarters in Silicon Valley.

Un volta che il sistema operativo è pronto passiamo alla customizzazione per poter ospitare il database Oracle 19.

Per configurare al meglio un server che ospiterà un database occorre creare 3 principali File System:
/u01 – FS dove saranno posizionati i binari di Oracle
/datiDBTEST – FS dove saranno posizionati i dati
/fraDBTEST – FS dove saranno posizionati gli archive

%MINIFYHTMLab0701b43098d13aaa7febb008420ed653% %MINIFYHTMLab0701b43098d13aaa7febb008420ed654%

Quindi procederemo con la creazione dei dischi con le seguenti dimensioni:
/u01 – 20G
/datiDBTEST – 20G
/fraDBTEST – 20G

Procediamo a macchina spenta con la creazione a livello fisico dei dischi sulla sezione archiviazione come la seguente immagine:

Click su aggiungi un disco fisso:

Diamo il nome al disco u01 e impostiamo la dimensione a 20G come da seguente immagine:

Ripetiamo l’operazione per gli altri due dischi sempre da 20G con nomenclature datiDBTEST e fraDBTEST.

Quando abbiamo terminato, occorre prima creare la partizione del disco e successivamente formattarlo in ext4, quindi avviamo la macchina e digitiamo

fdisk -l

Questi saranno i 3 dischi da 20Gb aggiunti e saranno identificati sul sistema operativo come device sd:

/dev/sdb
/dev/sdc
/dev/sdd

Disk /dev/sdc: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdd: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Ancora sono dischi inutilizzabili poiché occorre creare la partizione sempre con il tool di sistema fdisk come di seguito riportato:

fdisk /dev/sdb

n

<Invio>

<Invio>

<Invio>

w

Verifichiamo che sia stata la partizione /dev/sdb1:

fdisk -l

Se vedete la partizione la formattiamo in ext4 con il comando mkfs.ex4 /dev/sdb1:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed655%%MINIFYHTMLab0701b43098d13aaa7febb008420ed656%

mkfs.ext4 /dev/sdb1

Creiamo la directory:

mkdir /u01 

Montiamo il device formattato nel Mount point /u01:

mount /dev/sdb1 /u01

Ripetiamo l’operazione per gli altri 2 File System.

Prima di ripetere le operazioni, creiamo in precedenza le seguenti directory per poi montarle come da procedura precedente:

mkdir /datiDBTEST
mkdir /fraDBTEST

Per poter permettere di far montare i dischi in automatico vanno aggiunti i file system nel file /etc/fstab.
Quindi copiare e incollare le seguenti righe con l’fstab:

vi /etc/fstab
#FS Oracle
/dev/sdb1 /u01        ext4    defaults        0 0
/dev/sdc1 /datiDBTEST        ext4    defaults        0 0
/dev/sdd1 /fraDBTEST        ext4    defaults        0 0

%MINIFYHTMLab0701b43098d13aaa7febb008420ed657% %MINIFYHTMLab0701b43098d13aaa7febb008420ed658%

Creiamo gruppo dba:

groupadd dba

Creiamo l’utente oracle:

useradd -g dba oracle

Cambiamo la password dell’utente oracle:

passwd oracle

Creiamo la directory che sarà l’ORACLE_HOME del database con il seguente comando:

mkdir -p /u01/app/oracle
mkdir -p /u01/app/oraInventory
mkdir -p /u01/app/oracle/product/19.0.0/dbhome_1

Cambiamo proprietario e permessi dei FS.

Change Owner:

chown -R oracle:dba /u01
chown -R oracle:dba /datiDBTEST
chown -R oracle:dba /fraDBTEST

Change Mode:

chmod -R 775 /u01
chmod -R 775 /datiDBTEST
chmod -R 775 /fraDBTEST

Ora che abbiamo configurato storage e permessi, procediamo con l’installazione delle dipendenze:

yum install -y binutils 
yum install -y targetcli
yum install -y sysstat             
yum install -y nfs-utils
yum install -y make
yum install -y libstdc++-devel
yum install -y rdma-core-devel
yum install -y libXtst
yum install -y libXi
yum install -y libXrender-devel
yum install -y libaio-devel
yum install -y ksh
yum install -y glibc-devel
yum install -y fontconfig-devel
yum install -y elfutils-libelf-devel 
yum install -y libnsl

Per poter aprire gli archivi scaricati dal sito della oracle dobbiamo scaricare gzip con il seguente comando:

yum install -y zip unzip

%MINIFYHTMLab0701b43098d13aaa7febb008420ed659%%MINIFYHTMLab0701b43098d13aaa7febb008420ed660%

Installiamo l’X server per permettere l’avvio dell’interfaccia grafica durante l’installazione:

yum install xorg-x11-server-Xorg xorg-x11-xauth.x86_64 -y
yum install xdpyinfo -y 

Modifica dei parametri del Kernel. Editare i seguenti parametri sul file /etc/sysctl.conf

vi /etc/sysctl.conf
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2251799813685247
kernel.shmmax = 2987162112
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586

Modifica dei limiti di risorse dell’utente Oracle. Editare con i seguenti parametri il file /etc/security/limits.conf

vi /etc/security/limits.conf
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

Configuriamo le variabili d’ambiente sul file .bash_profile dell’utente oracle:

vi /home/oracle/.bash_profile
ORACLE_BASE=/u01/app/oracle
export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/19.0.0/dbhome_1
export ORACLE_HOME
ORACLE_SID=DBTEST 
export ORACLE_SID
PATH=$ORACLE_HOME/bin:$PATH
export PATH
export CV_ASSUME_DISTID=RHEL7.6

Scarichiamo il software oracle .zip dal seguente link Oracle database 19c Download

Una volta scaricato, ci colleghiamo con MobaXterm con l’utente oracle, sulla sinistra della pagina apriamo la scheda sftp e trasferiamo il file come da immagine sulla directory ORACLE_HOME che abbiamo che creato in precedenza:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed661%%MINIFYHTMLab0701b43098d13aaa7febb008420ed662%

Installazione Oracle 19 su Oracle Linux 8 in VirtualBox 6

Ci colleghiamo al server con l’utente Oracle ed estraiamo i file dall’archivio zip ed avviare l’installazione con il seguente comando:

cd /u01/app/oracle/product/19.0.0/dbhome_1
unzip LINUX.X64_193000_db_home.zip
./runInstaller

%MINIFYHTMLab0701b43098d13aaa7febb008420ed663%%MINIFYHTMLab0701b43098d13aaa7febb008420ed664%

Se tutto è stato configurato correttamente vedremo finalmente l’immagine dell’installer:

Procediamo con la configurazione

Come prima impostazione installiamo solo il software come da seguente immagine:

Secondo step Single instance database installation:

Per il nostro ambiente di test, configuriamo l’installazione Enterprise Edition:

Confermiamo la location dell’ORACLE_BASE e dell’ORACLE_HOME:

Impostiamo la location dell’oraInventory come da seguente immagine:

Impostiamo a tutti il gruppo dba come da immagine:

Impostare la password dell’utente root per eseguire gli step post installazione in automatico:

Nello step Summary verifichiamo se i path impostati sono tutti corretti ed eseguiamo Install:

Poco prima del termine dell’installazione ci verrà richiesto di eseguire gli script finali con le credenziali fornite in fase di configurazione, quindi confermiamo e attendiamo il termine.

%MINIFYHTMLab0701b43098d13aaa7febb008420ed665% %MINIFYHTMLab0701b43098d13aaa7febb008420ed666%

A questo punto abbiamo installato il prodotto Oracle 19c.

E’ rimasto che creare il database e il listener con il comando:

dbca

La prima immagine confermiamo Create a database come da immagine:

Andiamo con Advanced configuration:

Confermiamo il Database type con Oracle Single Intance database e lasciamo General Purpose or Transaction Processing:

Per questo tutorial installiamo un database classico quindi leviamo il nome da database Container e impostiamo il nome del database come DBTEST:

Impostiamo il disco dei dati che abbiamo creato all’inizio del tutorial come da immagine riportata:

Abilitiamo la Flash Recovery Area e impostiamo il FS degli archive:

Creiamo il listener come da immagine:

Lo step successivo lasciamo tutto invariato come da immagine:

Continuiamo!

Lasciamo la configurazione della SGA e della PGA con l’ASMM Automatic Shared Memory Management come da immagine:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed667% %MINIFYHTMLab0701b43098d13aaa7febb008420ed668%

Sulla scheda sizing lasciamo invariato, sulla scheda CharcterSets impostiamo Territory impostiamo Italy come da immagine:

Sulla scheda Connection mode lasciamo invariato e sulla scheda Sample schemas impostiamo il flag per avere gli schema di esempio per effettuare i propri test:

Rimuviamo il flag dall’Enterpris Manager come da immagine:

Impostiamo la password degli utenti SYS e SYSTEM:

Lasciamo invariato e andiamo avanti:

Controlliamo il Summary che le impostazioni messe siano configurate correttamente:

Se tutto è corretto procediamo con l’installazione.

FINE

%MINIFYHTMLab0701b43098d13aaa7febb008420ed669%%MINIFYHTMLab0701b43098d13aaa7febb008420ed670%

Come da immagine successiva, vediamo che, sia il database che il listener sono Up e Running e il test di connessione ha dato esito positivo.

[[email protected] ~]$ ps -ef |grep pmon
oracle   10965     1  0 05:44 ?        00:00:00 ora_pmon_DBTEST
oracle   19049 18860  0 06:05 pts/0    00:00:00 grep --color=auto pmon
[[email protected] ~]$ ps -ef |grep tns
root        46     2  0 04:08 ?        00:00:00 [netns]
oracle    5584     1  0 05:33 ?        00:00:00 /u01/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr LISTENER_DBTEST -inherit
oracle   19081 18860  0 06:05 pts/0    00:00:00 grep --color=auto tns
[[email protected] ~]$ sqlplus system/[email protected]

SQL*Plus: Release 19.0.0.0.0 - Production on Sat Nov 9 06:05:32 2019
Version 19.3.0.0.0

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

Last Successful login time: Sat Nov 09 2019 06:04:58 +01:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL>

Come estendere un TABLESPACE Oracle

Come estendere un TABLESPACE Oracle

Come estendere un TABLESPACE Oracle.
Le tablespace sono la più grande area di memorizzazione del database Oracle,
dove all’interno risiedono tabelle, indici e gli altri oggetti del database.
In fase d’installazione vengono create 5 tablespace indispensabili per il corretto funzionamento del database, che sono:
i tablespace SYSTEM e SYSAUX dedicate al sistema,
l’UNDO tablespace dedicato alla gestione delle transazioni,
il tablespace USERS dedicato agli utenti dei database oracle e
il tablespace TEMP utilizzato dal database per appoggiare i dati durante un ordinamento.

%MINIFYHTMLab0701b43098d13aaa7febb008420ed671%%MINIFYHTMLab0701b43098d13aaa7febb008420ed672%

Oltre a questi ci saranno i tablespace dedicati all’applicazione, che saranno composti (se creati con un organizzazione corretta) dai tablespace DATI, tablespace INDICI e tablespace dedicati ai LOB.

%MINIFYHTMLab0701b43098d13aaa7febb008420ed673%%MINIFYHTMLab0701b43098d13aaa7febb008420ed674%

Entriamo nel database con il comando sqlplus e accediamo con utente /as sysdba.

Se non abbiamo il nome del tablespace in allarme,
cerchiamo tra i tablespace con carenza di spazio libero presenti nel database,
attraverso lo statement della pagina Query per vedere le dimensioni di tutte le TABLESPACE del database Oracle

Una volta individuato il tablespace, verifichiamo se è presente un data file aperto su un file system o su un Disk Group ASM (a seconda di come è gestito lo storage), dove è presente spazio utile attraverso lo statement della pagina Query per vedere i DATAFILE con le relative dimensioni di una TABLESPACE.

Nel caso in cui il tablespace fosse gestito con data file aperti con una size fissa eseguiremo il comando:

alter database datafile '/path/nome_datafile' resize --dimensione_datafile;

Esempio:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed675%%MINIFYHTMLab0701b43098d13aaa7febb008420ed676%

alter database datafile '/DBTEST_DATI/DBTEST/DATI01.DBF' resize 512m;

Nel caso in cui un tablespace è gestito con datafile con una size dinamica eseguiremo il comando:

alter database datafile '/path/nome_datafile' autoextend on next --dimensione_extent maxsize --dimenizione_maxsize;

Esempio:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed677%%MINIFYHTMLab0701b43098d13aaa7febb008420ed678%

alter database datafile '/DBTEST_DATI/DBTEST/DATI01.DBF' autoextend on next 128m maxsize 1024m;

Nel caso in cui volessimo aggiungere un nuovo datafile, dobbiamo prima individuare il File System o il Disk Group ASM con spazio libero.

Comando per vedere spazio free sul FS:

df -h

Query per vedere spazio free sul DG ASM recuperabile al seguente link Query per vedere gli spazi dei DiskGroup ASM.

Una volta trovato lo spazio, cerchiamo il numero sequenziale del data file da creare individuabile dal seguente link Query per vedere i DATAFILE con le relative dimensioni di una TABLESPACE.

E procediamo all’estensione del tablespace con il comando:

Tablespace gestita con una size fissa:

alter tablespace --nome_tablespace add datafile '/path/nome_datafile03' size --dimensione_datafile;

Esempio:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed679%%MINIFYHTMLab0701b43098d13aaa7febb008420ed680%

alter tablespace DATI add datafile '/DBTEST_DATI/DBTEST/DATI03.dbf' size 2048m;

Tablespace gestita con una size dinamica:

alter tablespace --nome_tablespace add datafile '/path/nome_datafile03' size --dimensione_initial_extent autoextend on next --dimensione_extent_successivi maxsize --dimensione_maxsize;

Esempio:

%MINIFYHTMLab0701b43098d13aaa7febb008420ed681%%MINIFYHTMLab0701b43098d13aaa7febb008420ed682%

alter tablespace DATI add datafile '/DBTEST_DATI/DBTEST/DATI03.dbf' size 256m autoextend on next 256m maxsize 5096m;

Se avete dubbi non esitate a scrivere sui commenti.

%MINIFYHTMLab0701b43098d13aaa7febb008420ed686%
Wordpress Social Share Plugin powered by Ultimatelysocial