jueves, 20 de octubre de 2016

Identificar partición de un disco de ASM

Hay varios métodos para localizar el dispositivo físico o partición de un disco de ASM. Cuando se crea un disco de ASM a partir de una partición le asignamos una etiqueta, la cual se puede consultar con el comandooracleasm listdisks
# /etc/init.d/oracleasm listdisks
DATA01
FRA01
[...]
Para encontrar el mapeo contra la partición de disco, podemos utilizar el comando blkid, que muestra tanto el dispositivo físico como la etiqueta y el tipo, oracleasm en este caso:
# /sbin/blkid |grep asm
/dev/sdc3: LABEL="DATA01" TYPE="oracleasm"
Otra alternativa es listar los dispositivos de oracleasm (discos) ubicados en /dev/oracleasm/disks/. Al listarlos del siguiente modo encontraremos dos columnas que indican el major/minor del dispositivo respecto a la partición:
$ ls -l /dev/oracleasm/disks/ | more
total 0
brw-rw----. 1 grid dba  8,  81 ene 21 09:43 DATA01
brw-rw----. 1 grid dba  8, 241 ene 21 09:43 FRA01
Y con esos dos identificadores podremos encontrar la partición asociada a través de /proc/partitions:
$ grep 241 /proc/partitions 
   8      241   52428784 sdp1

Tomado de : http://rm-rf.es/identificar-particion-de-un-disco-de-asm/
Publicadas por a la/s No hay comentarios.:

lunes, 2 de mayo de 2016

Oracle 11gr2 : Problemas con ASM y Cluster Synchronization Service

Oracle 11gr2 : Problemas con ASM y Cluster Synchronization Service


En un ambiente con motor Oracle 11gr2 montado sobre uns instancia ASM versión 11gr2, que proviene de la instalación del Grid Infraestructure, ocurre un problema para levantar la instancia ASM, de hecho aparece el siguiente error

ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service

Para poder resolver ese inconveniente debemos llevar a cabo los siguientes pasos
Seteamos nuestro ambiente para la instancia ASM
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=+ASM
export PATH=$PATH:/u01/app/oracle/product/11.2.0/grid/bin

Y procedemos a levantar la instancia ASM
[oracle@oracle11g ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 05:37:25 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service
SQL>

¿Cómo solucionamos este inconveniente?
Pues he acá la explicación 
El demonio del Cluster Synchronization Service (cssd daemon) no queda online después del reboteo y como la instancia ASM , necesita ese demonio, pues por eso ASM no levanta
La forma de chequearlo
[oracle@oracle11g ~]$ crsctl check cssd
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
[oracle@oracle11g ~]$ crsctl check has
CRS-4638: Oracle High Availability Services is online
[oracle@oracle11g ~]$ ps -fea | grep d.bin
oracle 6208 1 0 Apr15 ? 00:02:37 /u01/app/oracle/product/11.2.0/grid/bin/ohasd.bin reboot

Y efectivamente vemos que el servicio está abajo ... aunque el servicio ohasd este online

¿Cuál es la causa de este inconveniente?
Pues a partir de Oracle11gr2 los demonios cssd y diskmon no son levantados vía el oratab, ahora estos demonios son levantados por el HAS (High Availability Service) y registrados en un OCR local como un recurso más.
Para analizar esto, procedemos a ir al HOME de la instalación del Grid Infraestructure, que en el fondo es el HOME que soporta el ASM
Y analizamos los recursos existentes
[oracle@oracle11g ~]$ cd $ORACLE_HOME
[oracle@oracle11g grid]$ pwd
/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g grid]$ cd bin
[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE

Como vemos , ambos demonios , inscritos como recursos se encuentran OFFLINE
Para ver el origen del problema, analizamos los recursos con su configuración en detalle
Nota : Solamente vamos a mostrar los recursos que tienen problemas (CSSD y DISKMON)
[oracle@oracle11g bin]$ ./crsctl status resource -p
NAME=ora.cssd
TYPE=ora.cssd.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/cssdagent%CRS_EXE_SUFFIX%
AGENT_HB_INTERVAL=0
AGENT_HB_MISCOUNT=10
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=30
CLEAN_ARGS=abort
CSSD_PATH=%CRS_HOME%/bin/ocssd%CRS_EXE_SUFFIX%
CSS_USER=oracle
DEGREE=1
DESCRIPTION="Resource type for CSSD"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
OMON_INITRATE=1000
OMON_POLLRATE=500
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
PROCD_TIMEOUT=1000
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=600
START_DEPENDENCIES=weak(concurrent:ora.diskmon)
START_TIMEOUT=600
STOP_DEPENDENCIES=hard(shutdown:ora.diskmon)
STOP_TIMEOUT=900
UPTIME_THRESHOLD=1m
VMON_INITLIMIT=16
VMON_INITRATE=500
VMON_POLLRATE=500
NAME=ora.diskmon
TYPE=ora.diskmon.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/orarootagent%CRS_EXE_SUFFIX%
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=20
CHECK_TIMEOUT=10
DEGREE=1
DESCRIPTION="Resource type for Diskmon"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
RESTART_ATTEMPTS=10
SCRIPT_TIMEOUT=60
START_DEPENDENCIES=weak(concurrent:ora.cssd)pullup:always(ora.cssd)
START_TIMEOUT=60
STOP_TIMEOUT=60
UPTIME_THRESHOLD=5s
USR_ORA_ENV=ORACLE_USER=oracle
VERSION=11.2.0.1.0

La propiedad AUTO_START esta seteada como NEVER o como 2 , para los demonios CDDS y DISKMON, esto implica que estos recursos no serán levantados nunca en un reincio por el HAS, y si el Cluster Synchronization Service no puede levantar, implica que la instancia ASM no puede partir.
Para solucionar el problema se debe configurar el AUTO_START para esos demonios (diskmon y cssd)
[oracle@oracle11g bin]$ ./crsctl modify resource "ora.cssd" -attr "AUTO_START=1"
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$ ./crsctl modify resource "ora.diskmon" -attr "AUTO_START=1"
[oracle@oracle11g bin]$

Una vez ejecutados esos comandos, procedemos a analizar nuevamente la configuración de los recursos
NAME=ora.cssd
TYPE=ora.cssd.type
AUTO_START=1
NAME=ora.diskmon
TYPE=ora.diskmon.type
AUTO_START=1

Verificamos los recursos y su estado actual
[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE
[oracle@oracle11g bin]$

Como podemos apreciar, ahora se encuentran con un TARGET ONLINE, lo que implica que se reiniciarán con un reboteo..
Pero se aprecia que el STATE es OFFLINE, eso implica que no están arriba los recursos, procedemos a levantarlos
[oracle@oracle11g bin]$ ./crs_start -all
Intentando iniciar `ora.cssd` en el miembro `oracle11g`
Intentando parar `ora.diskmon` en el miembro `oracle11g`
La parada de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.diskmon` en el miembro `oracle11g`
El inicio de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
El inicio de `ora.cssd` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.asm` en el miembro `oracle11g`
El inicio de `ora.asm` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.DATA.dg` en el miembro `oracle11g`
El inicio de `ora.DATA.dg` en el miembro `oracle11g` se ha realizado correctamente.

Y los volvemos a verificar
[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE oracle11g
ora.asm
ONLINE ONLINE oracle11g Started
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE ONLINE oracle11g
ora.diskmon
1 ONLINE ONLINE oracle11g

Ahora procedemos a levantar nuestra instancia ASM
Vale la pena recordar, que la instancia ASM ya no se levanta con el rol SYSDBA, existe uno nuevo llamado SYSASM , si nos conectamos con SYSDBA, aparecerá un error de privilegios
[oracle@oracle11g bin]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 06:05:11 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> startup
ORA-01031: insufficient privileges
SQL>

Nos conectamos con el rol indicado y procedemos a subir la instancia ASM
SQL> conn / as sysasm
Connected.
SQL> startup
ASM instance started
Total System Global Area 284565504 bytes
Fixed Size 1336036 bytes
Variable Size 258063644 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted

Tomado de :
http://www.oracleyyo.com/index.php/2010/04/19/oracle-11gr2-problemas-con-asm-y-cluster
Publicadas por a la/s No hay comentarios.:

Montar una carpeta compartida en VirtualBox

Montar una carpeta compartida en VirtualBox


Hoy he estado trasteando desde Windows 7 con una máquina virtual con Red Hat 5 Enterprise instalado. Necesitaba ver desde la máquina virtual una carpeta de mi ordenador local por lo que utilicé las herramientas gráficas de VirtualBox para crear la carpeta compartida tal y como se muestra en las siguientes imágenes pero no veía la carpeta compartida no aparecía por ningún sitio:

Para solucionarlo nada tan fácil como crear un punto de montaje, por ejemplo en/media/vboxshared y montar nuestra carpeta en ese directorio con el siguiente comando:
mount -t vboxsf <<carpeta_compartida>> /media/vboxshared
En mi caso:
mount -t vboxsf portal /media/vboxshared
Tomado de:
http://deckerix.com/blog/montar-una-carpeta-compartida-en-virtualbox/

Publicadas por a la/s No hay comentarios.:

jueves, 28 de abril de 2016

Error al iniciar la consola enterprise - oracle_unqname tips

oracle_unqname tips

Question:  I need to understand how the oracle_unqname environmental variable works in 11g.
Answer:  The oracle_unqname an OS environmental variable that defines the database unique name.  The oracle_unqname is used in 11g and beyond to enable OEM.  You can see this value with this query:
select
   name,
   db_unique_name
from
   v$database;
If you have not defined oracle_unqname you will see this error when starting OEM:

C:\> emctl status dbconsole

Environment variable ORACLE_UNQNAME not defined.
Please set ORACLE_UNQNAME to database unique name 


Here is hot to set oracle_unqname in Windows.  You use a similar "export command" in UNIX/Linux:
C:\>set ORACLE_HOSTNAME=localhost

C:\>set ORACLE_UNQNAME=orcl

C:\>set ORACLE_SID=orcl

C:\>emctl status dbconsole

Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0
Copyright (c) 1996, 2015 Oracle Corporation. All rights reserved.


Tomado de :
http://www.dba-oracle.com/t_oracle_unqname.htm
Publicadas por a la/s No hay comentarios.:

Arranque y parada de una base de datos Oracle

1. Objetivos

Explicar brevemente los diferentes métodos para parar y arrancar una base de datos ORACLE.

2. Arrancar base de datos

El arranque de una base de datos ORACLE requiere tres etapas
1. Arrancar la instancia
2. Montar la base de datos
3. Abrir la base de datos
  • Arrancar la base de datos
En esta parte del arranque se generan los procesos background.

Se crea la SGA. Sus dimensiones se basan en el fichero de inicialización "init.ora".

SQLPLUS> connect sys as sysdba connected SQLPLUS> startup nomount Oracle Instance started
  • Montar la base de datos
En esta parte del proceso de arranque se produce la conexión al/los archivo/s de control.

En este estado se puede:
- Cambiar el modo de archivado de la B.D.
- Renombrado de archivos de Redo Log o del asociado al tablespace SYSTEM
- Crear, modificar o suprimir nuevos Redo Log o grupos de Redo Log

Partiendo del anterior estado ( nomount ), montamos la base de datos de la siguiente forma:
SQLPLUS> alter database mount database mounted

En caso de que queramos iniciar la base de datos en este estado bastaría con hacer lo siguiente:
SQLPLUS> connect sys as sysdba connected SQLPLUS> startup mount Oracle Instance started Database mounted   
  • Abrir base de datos

En esta parte de proceso abren todos los ficheros asociados a los tablespaces y los ficheros de Redo Log.

La B.D. está accesible para todos los usuarios

Si es necesaria una recuperación (por un fallo de luz o CPU), se produce en este momento.

Partiendo del anterio estando ( mount ), abrimos la base de datos de la siguiente forma:
SQLPLUS> alter database open database opened
En caso de que queramos iniciar la base de datos en este estado bastaría con hacer lo siguiente:
SQLPLUS> connect sys as sysdba connected SQLPLUS> startup Oracle Instance started Database opened

3. Más alternativas para el arranque de base de datos

Arranque solo para usuarios con el privilegio RESTRICTED SESSION
SQLPLUS> startup restrict
Arranque forzado
SQLPLUS> startup force
Arranque con un fichero de parámetros distinto al habitual o localizado en una situación diferente a donde se encuentra por defecto
SQLPLUS> startup pfile=/oracle/database/init2.ora

4. Parada base de datos

La parada de una B.D. Oracle se realiza mediante el comando SHUTDOWN desde SQL*DBA después de haber establecido una conexión como SYS AS SYSDBA

Existen tres tipos de shutdown:
1. shutdown normal
2. shutdown immediate
3. shutdown abort
  • Shutdown normal
Espera a que los usuarios conectados actualmente finalicen TODAS las operaciones.
Evita nuevas conexiones. Los usuarios que intentan conectarse reciben el mensaje "Shutdown in progress".
Cierra y desmonta la B.D. Cierra la SGA para los procesos background.
No necesita recuperacion al arrancar la base de datos.
SQLPLUS> connect sys as sysdba connected SQLPLUS> shutdown normal

  • Shutdown immediate
Espera a que las transacciones actuales se completen.
Evita nuevas transacciones y nuevas conexiones. Los usuarios que intentan conectarse o los que ya están conectados al intentar realizar una nueva transacción reciben el mensaje "Shutdown in progress".
El proceso PMON finaliza las sesiones no activas y realiza ROLLBACK de aquellas transacciones que no estén validadas.
Cierra y desmonta la B.D. Cierra la SGA para los procesos background.
No necesita recuperacion al arrancar la base de datos.
SQLPLUS> connect sys as sysdba connected SQLPLUS> shutdown immediate

  • Shutdown abort
Parada drástica, no espera a que los usuarios conectados actualmente finalicen sus transacciones. El usuario conectado recibe el mensaje "No logged on".
No se realiza ROLLBACK de las transacciones pendientes.
El proceso PMON finaliza las sesiones no activas y realiza ROLLBACK de aquellas transacciones que no estén validadas.
SI necesita recuperacion al arrancar la base de datos.

SQLPLUS> connect sys as sysdba connected SQLPLUS> shutdown abort
 
 
Tomado de:
http://www.orasite.com/instalacion-y-configuracion/arranque-y-parada-de-una-base-de-datos-oracle

Publicadas por a la/s No hay comentarios.:

viernes, 22 de abril de 2016

Ampliar tamaño de discos duros en virtualbox windows

El siguiente tutorial te explica como redimensionar un disco duro virtual  (VDI) de VirtualBox de Oracle
Es habitual que al crear una máquina virtual seamos prudentes y asignemos un tamaño moderado (en mi caso 25Gb).
El problema es que a la que trabajas con bases de datos o cualquier programa un poco consistente, enseguida se te queda pequeño.
Después de buscar varios tutoriales, y algunos parecidos a un manual de la nasa, al final me he decidido a crear uno más sencillito y que nos permite redimensionar el disco duro en un plis.
Procedimiento
  1. Abrir la ventana de Comandos CMD
  2. Irnos al directorio donde tengamos instalado virtual box
  3. Debemos localizar el disco duro (vdi) de nuestra máquina virtual
  4. Ejecutar el comando Vboxmanage.exe con los siguientes parámetros
    1. Primer parámetro: Tipo de comando –> modifyHD (modificar el tamaño del disco duro)
    2. Ruta del disco Duro Virtual (VDI) entre comillas (en mi caso mi disco duro se llama “W7 WebDev.vdi”
    3. Tipo de Modificación que queramos hacer –> –resize
    4. Por último el nuevo tamaño que queramos asignarle –> en mi caso 35Gb (35000)
Así deberiamos escribir lo siguiente desde el directorio VirtualBox.
vboxmanage.exe modifyhd "D:\VirtualBox\W7 WebDev.vdi" --resize 35000
y ya está,
En la máquina virtual, tendremos que ir a las propiedades de discos, y ampliar o extender el disco duro con la nueva capacidad

Tomado de :  

http://lluisvera.com/2015/03/ampliar-tamano-de-discos-duros-en-virtualbox-windows/
Publicadas por a la/s No hay comentarios.:
Etiquetas: , ,
Suscribirse a: Comentarios (Atom)