L'opzione Advanced Row Compression permette di comprire i dati inseriti o aggiornati con e senza direct-path. E' abilitato con il comando CREATE TABLE … ROW STORE COMPRESS ADVANCED ed è raccamandato per attività OLTP. Questa compressione fa si che i valori duplicati in righe e colonne in un data block sono memorizzate una sola volta all'inizio del blocco. Importante ricordare che ROW STORE COMPRESS ADVANCED e COMPRESS BASIC non sono supportati per tabelle con più di 255 colonne. Inoltre non è possibile droppare una colonna da una tabella che è compressa per operazioni direct-load,  sebbene sia possibile impostare una colonna di questo tipo come "unused". Caso 6   Creiamo una tabella senza compressione dei dati. SQL> create table test06                 as select * from dba_objects where rownum <= 10000; SQL>      ANALYZE TABLE test06 COMPUTE statistics; SQL>    select  blocks, pct_free , compression, compress_for                     from    user_tables

Con l'opzione "basic compression" il server oracle comprime i dati durante un bulk load come direct load o CREATE TABLE AS SELECT. E' raccomandato per bulk loading in data warehouses. Vediamo un esempio Caso 1   Creiamo una tabella senza compressione dei dati. SQL> create table test01            as           select * from dba_objects where rownum <= 10000; Per verificare l'integrità della struttura di una tabella, index, cluster, o materialized view usare  SQL> ANALYZE TABLE test01 COMPUTE statistics; Oracle aggiorna il Dictionary table con le informazioni sul numero di righe della tabella, lo spazio occupato e altre informazioni. Se la struttura è valida, non viene restituito alcun messaggio di errore.  Ad esempio, durante la convalida dell'indice, è possibile confermare che ogni voce nell'indice punta alla riga corretta della tabella associata. Se l'indice è danneggiato, puoi eseguire drop e create. Stessa cosa per una tabella, un indice o u

SQL> alter database move datafile '/path/vecchio_nome' to   '/nuovo_path/nuovo_nome'  ; Durante questa operazione è possibile eseguire query, dml e ddl.  Non eseguire lo shutdown del database e non mettere offline i datafile. Esempio Supponiamo di avere un datafile del tablespace T3 definito con la nomenclatura OMF (oracle managemente file) e creato nel path definito dal parametro  db_create_file_dest  Che si chiama o1_mf_t3_hpvqfw9t_.dbf e portarlo nel path più classico  /u01/app/oracle/oradata/sid/t3_001,dbf  SQL>  alter database move datafile '/u01/app/oracle/oradata/ORCL/pdbts/ORCL/B00FF1D59FD647B9E053C68E670A83EC/datafile/o1_mf_t3_hpvqfw9t_.dbf' to '/u01/app/oracle/oradata/ORCL/pdbts/t3_001.dbf';

I profili degli utenti sono letti nel file utlpwdmg.sql  sotto la direcotry $ORACLE_HOME/rdbms/admin. I valori di default sono visibili dalla seguente tabella  SQL> select * from DBA_PROFILES where profile='DEFAULT'; Accediamo ad un pluggable database e creiamo un'utenza: SQL> alter session set container=orclpdb; SQL> create user test01 identified by test01; Se invece vogliamo creare un profilo con verifica della password, possiamo usare una funzione definita dal database oracle che individuamo con la seguente query: SQL> select * from dba_objects             where object_name like '%VERIFY%'            and object_type = 'FUNCTION' OBJECT_NAME -------------------------------------------------------------------------------- ORA12C_VERIFY_FUNCTION VERIFY_FUNCTION_11G VERIFY_FUNCTION ORA12C_STRONG_VERIFY_FUNCTION ORA12C_STIG_VERIFY_FUNCTION Creiamo un profilo che impone dei requisiti sulle password degli utenti, sfruttando la funzione oracle ORA12C

Uno User deve inizare con una lettera e non può contenere caratteri speciali. Per creare un utente nel Container e che sia visibile nei suoi Pluggable database usare il prefisso C##. Si chiama  Common User  come quelli di tipo amministrativo che sono  "sys" e "system". Un  Local user  è invece è un utente creato all'interno di un pdb  ed uno stesso local user può essere creato in differenti pdb. Colleghiamoci al conainer root: SQL> conn /as sysdba SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL>  select username, common, con_id from CDB_USERS  order by username; USERNAME COM      CON_ID ---------- --- ----------------------------- SYS           YES               1 SYS           YES                3 HR                NO                3 L'utente SYS è comune al container e al pdb (con_id=3) mentre HR è un local user perché è definito solo nel pdb. All'interno del Root Container non si