You are hereBlogues / Blog
Blog
-
almudena (12 April 2013)
Detallo a continuación os pasos seguidos para provocar un bloque corrupto unha BD con ASM e levar a cabo unha restauración a nivel de bloque con RMAN. Elo é posible por estar traballando con unha BD Enterprise Edition. Mencionar tamén que se trata dun contorno de test.
1. Creamos tablespace/usuario/táboa e procemento para insertar filas.
14:25:39 SYS@orcl1> create tablespace bad_data_test_acc; Tablespace created. 14:27:32 SYS@orcl1> select file_name, file_id , tablespace_name from dba_data_files 14:27:42 2 where tablespace_name like '%BAD%'; FILE_NAME FILE_ID TABLESPACE_NAME... -
almudena (15 October 2012)
Temos dúas opcións para eliminar un proceso export data pump.
1) Dende a línea de comandos do expdp vía CRTL+C
Partimos da execución dende línea de comandos do expdp é queremos parar a súa execución.[oracle@oracle bin]$ $ORACLE_HOME/bin/expdp "'/ as sysdba'" full=y FLASHBACK_TIME=\"TO_TIMESTAMP\(TO_CHAR\(SYSDATE,\'YYYY-MM-DD HH24:MI:SS\'\),\'YYYY-MM-DD HH24:MI:SS\'\)\" directory=acc_data_pump_dir dumpfile=expdp_proba.dmp logfile=expdp_proba.log Export: Release 11.2.0.3.0 - Production on Mon Oct 15 12:45:11 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 11g Release 11.2.0.3.0 - 64bit Production Starting "SYS"."SYS_EXPORT_FULL_01": "/******** AS SYSDBA" full=y FLASHBACK_TIME="TO_TIMESTAMP(TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS'),'YYYY-MM-DD...
-
almudena (28 September 2012)
Partimos dunha situación onde temos un DG, PRODATA, ao 91% de ocupación que é, polo tanto, preciso ampliar e empregaremos para elo un disco que pertence a doutro DG, FRAOLD, que está ao 6%:
select name,state,total_mb,free_mb, round(((total_mb-free_mb)/total_mb)*100,0)||'%' as pct_used from v$asm_diskgroup; NAME STATE TOTAL_MB FREE_MB PCT_USED -------------------------------------------------------------------------------- PRODATA MOUNTED 143353 13168 91% FRAOLD MOUNTED 61437 57928 6% PROFRA MOUNTED 81916 19312 76%
Consultamos en ASM os discos que ten o DG FRAOLD:SQL> set pages 100 column path format a20 column name format a20 select name,total_mb,path,header_status,mode_status from v$asm_disk where name like 'FRAOLD%'...
-
almudena (04 September 2012)
Para deshabilitar as estadísticas en 10g, será suficiente con executar:
EXECUTE DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
Esto aplica para unha 10g pero non para unha 11g. Neste último caso este job como tal non existe se non que está incluido dentro das AUTOTASKS:SQL> select job_name from dba_scheduler_jobs; JOB_NAME FROM DBA_SCHEDULER_JOBS; JOB_NAME ------------------------------ XMLDB_NFS_CLEANUP_JOB SM$CLEAN_AUTO_SPLIT_MERGE RSE$CLEAN_RECOVERABLE_SCRIPT FGR$AUTOPURGE_JOB BSLN_MAINTAIN_STATS_JOB DRA_REEVALUATE_OPEN_FAILURES HM_CREATE_OFFLINE_DICTIONARY ORA$AUTOTASK_CLEAN FILE_WATCHER PURGE_LOG SQLSCRIPT_776944 MGMT_STATS_CONFIG_JOB MGMT_CONFIG_JOB RLM$SCHDNEGACTION RLM$EVTCLEANUP SQL> SQL> select client_name,... -
alberto (20 June 2012)
Durante a fase de probas dun proxecto de ampliación dun RAC ó que se lle engadiron dous novos nodos, atopamos que existía unha incoherencia na zona horaria dos servidores para os usuarios propietarios do software RDBMS (curiosamente non detectada polas ferramentas de validación do clúster, para as que parece bastar a sincronización horaria sen fixarse na zona). As máquinas teñen sistema operativo Solaris 10.
oracle@rac1 [~]$ echo $TZ Europe/Madrid oracle@rac4 [~]$ echo $TZ MET
Tras detectar esta diferencia na configuración, o paso seguinte foi igualar tódolos servidores á zona horaria Europe/Madrid. Previamente á detección xa foran creadas, dende un dos novos servidores, bases de datos para a execución das probas de validación do clúster. Tras o cambio de zona horaria os axentes Grid Control (versión 11.1) dos servidores onde esta foi modificada caeron, deixando o seguinte erro na traza:
... -
alberto (24 May 2012)
Oracle certifica a execución conxunta de versións RAC 10gR2 e 11gR2, o que resulta moi últil cando por exemplo queremos facer unha actualización progresiva das nosas bases de datos, ou cando necesariamente precisamos diferentes versións por restricións a nivel de aplicación. Nestes casos podemos crear un clúster en versión 11.2 (nunca inferior) con bases de datos en versións 11.2 e 10.2 (ou inferior).
Unha das cousas que nos atopamos cando montamos unha configuración heteroxénea é que a realidade é un pouco mais complexa ca a teoría xa que existen varios bugs e incompatibilidades asociados ó emprego de BDs 10g en clúster 11.2, especialmente cando facemos emprego de separación de roles instalando a Grid Infrastructure (GI) con un usuario e o software RDBMS con outro. É imprescindible revisar a nota Metalink 948456.1 (Pre 11.2 Database Issues in 11gR2 Grid Infrastructure Environment) para revisar os potenciais perigos dun contorno mixto. A día de hoxe esta nota documenta mais...
-
alberto (24 May 2012)
Oracle introduciu na versión 11gR2 da solución RAC a posibilidade de administrar dinamicamente os nodos nos que as instancias das BDs poden estar a executarse. Até esta versión, á hora de crear unha BD RAC só era posible especificar os servidores sobre os que se creará unha instancia. Con 11gR2 é posible indicar unha cardinalidade de instancias e asociar a BD ó que se denomina un pool de servidores. Os pools de servidores son entidades dinámicas e en función da parametrización do pool e da dispoñibilidade dos servidores no clúster, un determinado servidor pertencerá a un pool ou a outro. Así, unha instancia de BD pode arrincar en diferentes nodos. Este comportamento, deseñado para un contorno complexo de múltiples nodos, pode verificarse nun RAC simple de dous nodos.
No noso exemplo, temos creada unha base de datos RAC administrada por políticas que está asignada a un pool de servidores. O pool de servidores chámase oracle e está composto polos dous nodos no que está instalada...
