Professional Documents
Culture Documents
System Saadproc
System Saadproc
IMSERSO
APPLIED RESEARCH
BUSINESS CRITICAL
ASSISTANCE
Registro de Cambios
Fecha Autor Versión Notas
Revisiones
Nombre Role
Distribución
Copia Nombre Empresa
1
2
3
4
Índice de Contenidos
En el Apendice B – Objetos de SYSTEM (Mayo 2009) hay un listado de los objetos del
tablespace SYSTEM a fecha 25 de mayo de 2009. Hay un total de 1688 segmentos en
dicho tablespace, que es un total de 8178 MB.
El listado de objetos que hay en SYSTEM a fecha 2 de julio de 2009, que ocupan 8750
MB, incluye los siguientes objetos nuevos:
OWNER SEGMENT_NAME SEGMENT_TYPE Kbytes EXTENTS
SYS SYS_C001362536 INDEX 2048 17
SYS SYS_C001364638 INDEX 2048 17
SYS SYS_C001366678 INDEX 576 9
SYS SYS_C001368899 INDEX 384 6
SYS SYS_C001371021 INDEX 128 2
SYS SYS_C001396401 INDEX 576 9
SYS SYS_C001396611 INDEX 128 2
SYS SYS_C001431365 INDEX 2048 17
SYS SYS_C001433411 INDEX 256 4
SYS SYS_EXPORT_FULL_77 TABLE 22528 37
SYS SYS_EXPORT_FULL_78 TABLE 22528 37
SYS SYS_EXPORT_FULL_79 TABLE 6144 21
SYS SYS_EXPORT_FULL_80 TABLE 3072 18
SYS SYS_EXPORT_FULL_81 TABLE 960 15
SYS SYS_EXPORT_FULL_82 TABLE 7168 22
SYS SYS_EXPORT_FULL_83 TABLE 704 11
SYS SYS_EXPORT_FULL_84 TABLE 22528 37
SYS SYS_EXPORT_FULL_85 TABLE 2048 17
SYS SYS_IL0000576284C00039$$ LOBINDEX 64 1
SYS SYS_IL0000576768C00039$$ LOBINDEX 64 1
SYS SYS_IL0000577457C00039$$ LOBINDEX 64 1
SYS SYS_IL0000578185C00039$$ LOBINDEX 64 1
SYS SYS_IL0000579109C00039$$ LOBINDEX 64 1
SYS SYS_IL0000587454C00039$$ LOBINDEX 64 1
SYS SYS_IL0000587839C00039$$ LOBINDEX 64 1
SYS SYS_IL0000598725C00039$$ LOBINDEX 64 1
SYS SYS_IL0000599404C00039$$ LOBINDEX 64 1
SYS SYS_LOB0000576284C00039$$ LOBSEGMENT 98304 83
SYS SYS_LOB0000576768C00039$$ LOBSEGMENT 98304 83
SYS SYS_LOB0000577457C00039$$ LOBSEGMENT 73728 80
SYS SYS_LOB0000578185C00039$$ LOBSEGMENT 64 1
SYS SYS_LOB0000579109C00039$$ LOBSEGMENT 64 1
SYS SYS_LOB0000587454C00039$$ LOBSEGMENT 90112 82
SYS SYS_LOB0000587839C00039$$ LOBSEGMENT 64 1
SYS SYS_LOB0000598725C00039$$ LOBSEGMENT 98304 83
SYS SYS_LOB0000599404C00039$$ LOBSEGMENT 64 1
Los siguientes usuarios tienen el tablespace SYSTEM como tablespace por defecto.
El uso normal de estos usuarios no implica que puedan ser los causantes del
crecimiento excesivo del tablespace SYSTEM de SAADPROC.
Objetos SYS_EXPORT_FULL_xx
Se comprueba que en db1, hay un job definido con crontab con la siguiente entrada:
#Cron del usuario oracle
00 21 * * * /home/oracle/export_oracle #export de Bd
El script que se lanza mediante este cronjob todos los días a las 21:00 es el siguiente:
# oracle_export : Backup de la Bd. oracle. se hace un cron
#
# Variables
ORACLE_HOSTNAME=saad_db
export ORACLE_HOSTNAME
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:
$ORACLE_HOME/bin:.
export PATH
particion=db1
export ORACLE_SID=SAADPROC
export ORACLE_HOME=/opt/oracle/app/oracle/product/10.2.0/db_1
ORACLE_HOSTNAME=saad_db
export ORACLE_HOSTNAME
fecha=`date +%d%m%y%H`
#fecha=`date +%d%m%y`
directorio=db1${fecha}
#directorio=db1testfecha
mkdir /testfs/db1export/${directorio}
EOT
/opt/oracle/app/oracle/product/10.2.0/db_1/bin/expdp 'userid="/ as
sysdba"' DIRECTORY=$directorio DUMPFILE=db1${fecha}.dmp LOGFILE=logdb1.log
FULL=y
#================================================
# Si acaba bien el export borrar el directorio anterior
if [ $? = 0 ]
then
echo resultado correcto
#Borrar el directorio anterior
borra=`head -1 /testfs/db1export/.control`
rm /testfs/db1export/${borra}/* /testfs/db1export/${borra}/.*
rmdir /testfs/db1export/${borra}
#
echo $directorio > /testfs/db1export/.control
else
echo El export tiene un error
echo no borro nada
fi
Tras revisar el script se observa que cada día se crea un directorio identificado con la
fecha en el filesystem /testfs/db1export/, donde se va a adejar el fichero
correspondiente a dicho export, así como el fichero de log del proceso.
De la lista anterior se puede deducir que el crontab job no se ha ejecutado todos los
días por algún motivo, o que se ha cambiado su frecuencia en varias ocasiones.
Uno de los logs de dichos jobs, el del 1 de julio del 2009, muestra los siguientes
errores:
db1:/testfs/db1export/db101070921> more logdb1.log
;;;
Export: Release 10.2.0.3.0 - 64bit Production on Wednesday, 01 July,
2009 21:00:00
De todos los directorios donde deberáin estar los logs y los dmp correspondientes a
los exports enviados, sólo los siguientes tienen contenido:
db101070921:
total 24
-rw-r----- 1 oracle oinstall 8192 Jul 01 21:03 db101070921.dmp
-rw-r--r-- 1 oracle oinstall 1706 Jul 01 21:03 logdb1.log
db120030921:
total 12825624
db120050921:
total 0
-rw-r----- 1 oracle oinstall 4096 May 20 21:00 db120050921.dmp
-rw-r--r-- 1 oracle oinstall 0 May 20 21:00 logdb1.log
db121050921:
total 0
-rw-r----- 1 oracle oinstall 4096 May 21 21:01 db121050921.dmp
-rw-r--r-- 1 oracle oinstall 0 May 21 21:01 logdb1.log
db122050921:
total 0
-rw-r----- 1 oracle oinstall 4096 May 22 21:00 db122050921.dmp
-rw-r--r-- 1 oracle oinstall 0 May 22 21:00 logdb1.log
db123050921:
total 0
-rw-r----- 1 oracle oinstall 4096 May 23 21:00 db123050921.dmp
-rw-r--r-- 1 oracle oinstall 0 May 23 21:00 logdb1.log
db128030921:
total 72648
-rw-r----- 1 oracle oinstall 37183488 Mar 28 21:21 db128030921.dmp
-rw-r--r-- 1 oracle oinstall 5518 Mar 28 21:21 logdb1.log
Todo apunta a que los jobs de datapump están fallando y se quedan parados, con la
Master table que se utiliza para las operaciones temporales quedándose en el
tablespace SYSTEM, a la espera de que se solucionen los problemas y se relance el
job de datapump.
ATTACHED_
OWNER_NAME JOB_NAME OPERATIONJOB_MODE STATE SESSIONS
SYS SYS_EXPORT_FULL_26EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_27EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_28EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_29EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_30EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_31EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_32EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_33EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_34EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_35EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_36EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_37EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_38EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_39EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_40EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_41EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_42EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_43EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_44EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_45EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_46EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_47EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_48EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_49EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_50EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_51EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_52EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_53EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_54EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_55EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_56EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_57EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_58EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_59EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_60EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_61EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_62EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_63EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_64EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_65EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_66EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_67EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_68EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_69EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_70EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_71EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_72EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_73EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_74EXPORT FULL NOT RUNNING 0
ATTACHED_
OWNER_NAME JOB_NAME OPERATIONJOB_MODE STATE SESSIONS
SYS SYS_EXPORT_FULL_75EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_76EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_77EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_78EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_79EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_80EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_81EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_82EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_83EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_84EXPORT FULL NOT RUNNING 0
SYS SYS_EXPORT_FULL_85EXPORT FULL NOT RUNNING 0
Hay 85 jobs de datapump parados,. Algunos desde el 3-8-2008, que están haciendo
que las masters tables correspondientes se hayan quedado pendientes en el
tablespace de SYSTEM.
Causas
Debido a que la utilidad Datapump crea los objetos temporales que necesita en el
tablespace por defecto del usuario que lanza el job, se hace necesario crear un
usuario privilegiado únicamente para estas labores de export/import.
• object privileges READ and WRITE on an valid directory object (or the
CREATE DIRECTORY privilege with which a valid directory object was
created)
Se debe tener en cuenta que estos privilegios se refieren al usuario que se conecta a
la base de datos para hacer el job de datapump, no sobre el usuario que es
importado o exportado.
Pasos a ejecutar
4. Cambiar el usuario del crontab job del export por el usuario creado
específicamente para los datapumps.
En, el menos, una traza del datapump se ha encontrado que el trabajo ha fallado por
un error del sistema operativo que no ha podido escribir el fichero correspondiente.
ORA-39125: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA
while calling KUPF$FILE.WRITE_LOB [USER:"28682891M"]
ORA-19502: write error on file
"/testfs/db1export/db101070921/db101070921.dmp", blockno 3
(blocksize=4096)
ORA-27063: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 28: No space left on device
Additional information: -1
Additional information: 4096
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.KUPW$WORKER", line 6234
Se debe revisar este filesystem, si tiene espacio suficiente, permisos de montaje, etc.
Así mismo, se debe revisar la definición del crontab del export y su frecuencia, ya
que según la definición debería ejecutarse diariamente, y faltan ficheros de log, si
hubiera sido así.
Se debe decidir si los jobs de datapunp parados (estado NOT RUNNING) no son
necesarios, y proceder a su purgado.
Para el purgado de los trabajos, se pueden seguir los pasos de la note 336014.1 - How
To Cleanup Orphaned DataPump Jobs In DBA_DATAPUMP_JOBS ?
Dado que los trabajos que hay en la base de datos de SAADPROC son de full export,
se pueden ignorar las secciones de dicha nota que se refieren a otro tipo de jobs.
Pasos a ejecutar
2. Asegurarse que los jobs que se van a purgar están todos en estado NOT
RUNNING. Confirmar con quien lanzó los jobs que no están trabajando y se
han parado por una causa justificada con el comando STOP_JOB, sino que
son jobs que realmente han fallado.
4. Para los trabajso que realmente se quieren purgar, borrar la master table
correspondiente.
6. Una vez que se para el job, tarda cierto tiempo en borrarse. Se deben
comprobar de nuevo las tablas dba_datapump_jobs y la dba_objects para
confirmar que los trabajos están borrados
CONNECT / as sysdba
SET lines 200
Por defecto los valores por defecto de VMM en sistemas AIX no suelen ser los
apropiados para su uso mediante bases de datos relacionales. Los valores por
defecto de AIX VMM permiten que se use hasta el 80% de la memoria física para el
buffering de I/O. Como Oracle ya está haciendo buffering de esa I/O en la SGA, los
mismos datos se están cacheando 2 veces, y además se está dejando sólo el 20% de la
memoria física para que se ejecute la base de datos y todos los otros programas.
Según los documentos de IBM; The goal of the new tuning approach is to prevent or
protect computational memory (i.e. process memory (data, stack, and heap), kernel memory
and shared memory (e.g., Oracle’s System Global Area (SGA)) from being paged-out to
paging space. Under the assumption that once paged-out, at some point in the future, the
data will have to be paged-in from paging space, which would negatively impact system
performance. Protecting computational memory is particularly important for applications
that maintain their own data cache (e.g., DB2 and Oracle). The objective, protecting
computational memory, is achieved by setting the VMM parameters as follows:
En el caso de que que se trate de versiones superiores a AIX 5.2 ML04 o AIX 5.3
ML01, como es el caso de Imserso que se trata de una versión AIX 5.3 ML05
A high value prevents the lrud1 from running unnecessarily, and if possible the
value should be greater than numclient% (reported by vmstat –v). A typical
setting is 90%.
A low value ensures that the setting for lru_file_repage isn’t overridden, and
should be less than numperm % (report by vmstat –v). Typical settings, based
on total system memory, are:
• strict_maxperm=0 (default)
• strict_maxclient=1 (default)
• lru_file_repage=0
• v_pinshm=1
• maxpin%=percent_of_real_memory
Conclusiones y Recomendaciones
Aparte del impacto que tiene que el tablespace SYSTEM haya crecido hasta los 10GB
de tamaño, los 85 trabajos de datapump no finalizados y parados, implican que los
exports realizados mediante este script no son completos, por lo que no se dispone
de backup lógico de la base de datos si sólo se tiene dicho export.
Las recomendaciones de este documento, sobre todo las referidas a establecer otro
usuario que realice los exports que no sea SYS harán que el tablespace de SYSTEM
no se siga llenando con tablas temporales, y por tanto su rendimiento no se vea
afectado.
Una vez que se eliminen del tablespace SYSTEM todos los objetos sobrantes, se
puede estudiar la posibilidad de ver como se puede reducir su tamaño.
Referencias
Note 413201.1 - Datapump Master Table, How Big is it, Can It Be Moved ?