06 agosto 2007

Archivelog RAC su ASM

Gli archivelog di un cluster Oracle 10g su ASM possono finire, a seconda della configurazione, su molteplici destinazioni, ma quella preferenziale è sempre sullo storage condiviso, come per il resto del database.
Se archiviate anche su filesystem, e quindi per ogni server avete un thread di redo diverso, fate attenzione alla consistenza dei log archiviati localmente durante un'eventuale caduta di uno dei nodi del cluster. A me è capitata un'inconsistenza, risolta esportando l'archivelog da ASM, dove evidentemente non c'è stato un problema di salvataggio del thread. Come è possibile? Basta usare il la procedura DBMS_FILE_TRANSFER.COPY_FILE.
Attenzione che i parametri di COPY_FILE sono sempre dei directory object, non delle directory vere e proprie; corrispondono, ai fini pratici, ad alias di locazioni nello storage accessibile alle istanze, tra cui ovviamente c'è il filesystem ASM:
SQL> CREATE DIRECTORY dir_name AS '+ASM/ciao';
creando sia la directory sorgente che quella di destinazione.

2 commenti:

clusterrac2 ha detto...

eciao .. e si a volte ASM sotto particolare "stress" incappa in un bug di quel tipo e qualche log_archive_dest puo andare in tilt,meno male che il DBA ha ridondato i file molto sensibili su destinazioni storage diverse (complimenti molto argutoeheh)

io userei una un blocco anonimo tipo questo che insiste sulle diretory oracle per automatizzare la tranfer :

set serveroutput on


spool log.log


declare

appoggio VARCHAR2(4000) := 'thread_number_' ;

appoggio2 number :=1174;

max_number number :=1177;
<
appoggio3 VARCHAR2(4000):= '_example_specification_arc
' ;


file_nome VARCHAR2(4000);

begin


DBMS_OUTPUT.ENABLE(2000000);



if appoggio2 < max_number

then

loop



file_nome:=appoggio||appoggio2||appoggio3;

dbms_output.put_line(file_nome);

DBMS_FILE_TRANSFER.COPY_FILE('SORG',file_nome ,'PROV',file_nome);

appoggio2 := appoggio2+1;

EXIT WHEN appoggio2 > max_number;

end loop;

end if;

end;
/


spool off

Rudy ha detto...

No, non è stato ASM ad incappare in un bug: l'archivelog inconsistente era su filesystem.

Dallo stile dell'SQL mi pare di conoscerti: ti chiami per caso Luca? :-)