RETENTION POLICY

-

 Esistono due parametri mutuamenti esclusivi che definiscono la retention policy:

 - Redundancy
Indica il numero di backup full o di livello 0 che devono essere disponibili contemporaneamente. Dopo aver selezionato il numero di copie di backup, tutti i backup più vecchi vengono contrassegnati come obsoleti. Ciò non pone alcun tipo di restrizione sulla durata di conservazione dei backup.

RMAN> configure retention policy to redundancy 2;

Vuol dire che vengono conservate due backup full o Level 0 del database e le restanti sono marchate come obsolete.
Il valore di default vale 1.


- Recovery Window
non si basa sul numero di copie di backup, ma sul numero di giorni per i quali si desidera avrer un backup ripristinabile. Quindi è possibile disporre di un numero n di copie entro il periodo specificato della finestra di ripristino. Qualsiasi backup più vecchio della finestra di ripristino è contrassegnato come obsoleto. 
Il valore di default è 7 giorni, il che significa che possono ripristinare un qualsisasi backup entro sette giorni da oggi.

Ad esempio se si dispone di un backup full nei giorni 8, 15 e 22 ed oggi è 25, RMAN considera la finestra di recovery di 7 giorni fino al 18. Ma se volessimo ripristinare il backup del 18 occorrerebbe partire dal bacup full del 15 e prendere gli archivelog fino al 18. Questo vuol dire che Rman per assicurare un riprisitino completo di 7 giorni dovrà conservare anche il backup full del 15, e cioè  il primo backup full al di fuori della recovery windows, e tutti gli archivelog che servono per avere un backup completo del db all'interno della finestra di recovery.

 

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;

Recovery window e Redundancy si escludono a vicenda.
Eseguire il comando seguende per individuare la policy.
RMAN> show retention policy;

Per impostare il valori di default:
RMAN> CONFIGURE RETENTION POLICY CLEAR;   

Post popolari in questo blog

ORA-12154: TNS: il listener non è attualmente a conoscenza del servizio richiesto nel descrittore di connessione

-
Richiesta: Problemi connessione oraSiSV9i.  Di seguito il tnsnames.ora.  SISV9I.dominio.IT = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(Host = oraSISV9I)(Port = 1521)) )(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = SISV9I))) errore che ricevo dall'applicazione: ORA-12514: TNS: il listener non è attualmente a conoscenza del servizio richiesto nel descrittore di connessione 1) Da una macchina server verifico che il ping funziona tnsping oraSISV9i TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 24-JAN-2019 12:05:31 Copyright (c) 1997, 2009, Oracle.  All rights reserved. Used parameter files: /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/sqlnet.ora Used HOSTNAME adapter to resolve the alias Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP) (HOST=xx.yyyy.zzz.n)(PORT=1521))) OK (0 msec) 2) Provare da un client locale , inserendo nel tnsnam
Continua a leggere

Create e Drop Pluggable Database

-
Immagine
Creare un pluggable database dal SEED. Il nome del pluggable database non è case sensitive. Condizioni: - Accedere al conatiner root come amministratore o avere il privilegio "create pluggable database". - Il CDB deve essere in stato READ e WRITE. - Usare il comando "create pluggable database" - Come best practice creare un utente che abbia il ruolo DBA all'interno del nuovo pdb La procedura prevede che vengano effettuate copie dei datafile del Seed in una nuova directory e creati i tablespace Sysaux, System, Undo e Temp e gli schema e gli utenti di deafult. Accediamo come root container e assicuriamoci che sia in stato Read Write SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL> column name format a15 SQL> select con_id,name,open_mode  from v$containers;       CON_ID NAME    OPEN_MODE ---------- --------------- ---------------------------- 1  CDB$ROOT    READ WRITE 2  PDB$SEED    READ ONLY 3  ORCLPDB            R
Continua a leggere