Post

Visualizzazione dei post da gennaio, 2019

Restore Oracle9i tramite HP Data Protector

Dobbiamo effettuare  il restore del db RATP versione Oracle 9i il cui backup è fatto con Hp Data Protector. Individuare un ambiente contenente il client Oracle9i dove creare un instanza ausiliaria. Il server in questione è oradbt04-test. Essendo due server differenti, l'istanza ausiliaria conserva lo stesso nome del db sorgente. 1) Inserire nel listener.ora sotto /u01/app/oracle/product/9.2.0/network/admin la stringa di connessione. (SID_DESC =       (GLOBAL_DBNAME = RATP)       (ORACLE_HOME = /u01/app/oracle/product/9.2.0)       (SID_NAME = RATP)     ) 2) Modificare il tnsnames.ora mettendo come host quello della macchina di test. RATP.WORLD =   (DESCRIPTION =     (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = oradbt04-test.intra.xxxxxx.it)(PORT = 1521))     )     (CONNECT_DATA =   (UR = A)       (SERVER = DEDICATED)       (SERVICE_NAME = RATP)     )   ) 3) Copiare spfile del db sorgente (oradbp06 )sulla macchina test (oradbt04-test). scp sp

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

ORA-25153: Temporary Tablespace is Empty

Dopo aver effettuato il restore e recover di un db ho provato a recuperare un package con la seguente query select dbms_metadata.get_ddl ('PACKAGE','nome_package','nome_Schema') from dual; ed  è comparso il seguente messaggio di errore: ORA-25153: Temporary Tablespace is Empty ORA-06512: at "SYS.DBMS_LOB", line 424 ORA-06512: at "SYS.DBMS_METADATA", line 579 ORA-06512: at "SYS.DBMS_METADATA", line 1260 ORA-06512: at line 1 Questo perché la tablespace TEMP non contiene file come visibile dalla seguente query: select tb.tablespace_name, tf.file_name  from dba_tablespaces tb left join dba_temp_files tf on tf.tablespace_name = tb.tablespace_name where tb.contents = 'TEMPORARY'; TABLESPACE_NAME               FILE_NAME                                                                      ------------------------------------------------------------ TEMP                                                           

Creare un RECOVERY CATALOG

Il repository data (metadati) di RMAN viene salvato nel Control file del db target, ma può essere anche salvato in un altro database di Oracle chiamato Recovery Catalog. Questo contiene le informazioni di backup, in un db separato ed è utile in caso di perdita del control file. Inoltre un singolo Recovery Catalog può contenere backup di più target database. Le informazioni di backup continuano ad essere memorizzate nel control file.  Quando usarlo? Se il backup è molto semplice conviene usare il control file perché avere un recovery catalog significa gestire ed  effettuare il backup di un altro db. Il vantaggio è che offre un tempo di retention di backup più lungo del control file e una redundanza nel caso si perda il control file. Non usare il database target come il db del Recovery Catalog perché questo deve essere protetto da una perdita  del db target. Assicurarsi che il recovery catalog e database target non risiedono nello stesso disco. RMAN propaga le informazioni sulla strut

UNDO Data

Immagine
-- Versione Oracle 11g Nelle operazioni di flashback query, flashback transaction e table o Recovery from failed transaction sono fondamentali gli Undo data. Gli  Undo Data  sono copie di dati sottoposti ad una transazione e sono mantenuti finché la transazione non termina con una commit, rollback, ddl o una sessione terminata "abnormally" o con il comando shutdown abort.  Quindi il tablespace Undo è come un tablespace temporaneo. I dati di undo sopravvivono alla chiusura del database. Ogni transazione è assegnata ad un solo Undo Segment ma un Undo Segment può service più transazioni contemporaneamente. Ogni volta che c'è una richiesta di update, il  server process  (vedi post  Listener: connessione - sessione ) copia alcuni blocchi di undo datafile nel Database Buffer Cache, e salva qui il valore dei dati prima della modifica. Finché non viene eseguita la commit i vecchi dati sono sempre visibili da una secondo utente che esegue la stessa query: è in questo che con

DBID

DBID sta per database identifier ed è l'identificativo univo del database. select * from v$database Se il control file è perso non si può mettere in stato mount il db e pertanto non si può eseguire la  query precedente. E' possibile utilizzare il comando seguente che scrive il DBID in un file di trace. Utilizzare con il db in stato nomount, SQL>startup nomount; SQL> alter system dump datafile '/u01/app/oracle/oradata/S11TEST1/S11TEST1/datafile/system01.dbf' block min 1 block max 10; System altered. Se apro il file S11TEST1_ora_30229.trc sotto /u01/app/oracle/diag/rdbms/s11test1/S11TEST1/trace trovo Start dump data block from file /u01/app/oracle/oradata/S11TEST1/S11TEST1/datafile/system01.dbf minblk 1 maxblk 10  V10 STYLE FILE HEADER:         Compatibility Vsn = 186646528=0xb200000         Db ID=4247218851 =0xfd276aa3, Db Name='S11TEST1' Il comando alter system dump scrive il contenuto dei blocchi oracle del datafile.

Configurazione del Device Type e del Channel

Di default il backup è effettuato su disco. RMAN> show all; RMAN configuration parameters for database with db_unique_name TEST1 are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default Per impostare il backup su tape eseguire il comando. RMAN> configure  DEFAULT DEVICE TYPE  to sbt; RMAN> show all; RMAN configuration parameters for database with db_unique_name TEST1 are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE'; Per ritornare al valore di default. RMAN> configure default device type to disk; oppure  RMAN> configure default device type clear; Quando viene effettuato il backup, RMAN di default alloca un canale su disco. Se si effettua il backup su tape occorre prima configurare un canale. RMAN> configure CHANNEL  D