Basándome en el query que pasaron en este foro completé un poco más la información obtenida, agregándole la sentencia que está bloqueando, y la bloqueada.
SELECT LPAD (' ', DECODE (l.xidusn, 0, 8, 0))
|| l.oracle_username "User Name",
o.owner, o.object_name, o.object_type, l.locked_mode, st.sql_text
FROM v$locked_object l,
dba_objects o,
v$session s,
v$sqltext_with_newlines st
WHERE l.object_id = o.object_id
AND l.session_id = s.SID
AND ( ( l.xidusn = 0
AND st.address = s.sql_address
AND st.hash_value = s.sql_hash_value
)
OR ( l.xidusn <> 0
AND st.address = s.prev_sql_addr
AND st.hash_value = s.prev_hash_value
)
)
ORDER BY o.object_id, 1 DESC, st.piece;
jueves, 7 de enero de 2010
lunes, 4 de enero de 2010
Pro*C: dbms_output.put_line
No sé por qué nunca se me ocurrió esto, pero bueh.
Nosotros estamos acostumbrados a sacar mensajes desde un PL/SQL siempre y cuando usemos el sqlplus:
$ sqlplus ***/***
SQL> set serveroutput on; <=== para que se vean los mensajes que mostremos con el dbms_output
SQL> begin
2 dbms_output.enable(null); <=== para habilitar un buffer sin límites
3 dbms_output.put_line('Hola Quique'); <=== "muestra el texto por pantalla" (nótese las comillas)
4 end;
5 / hola PL/SQL procedure successfully completed.
SQL>
Ahora, la incognita errónea que siempre nos preguntamos o al menos yo lo hice es, cómo implementamos la instrucción "set serveroutput on" desde Pro*C, si este es un comando de sqlplus? Y ete aquí que lo que está mal formulada es la pregunta o el concepto del put_line. put_line no muestra un texto, sino que pone un texto dentro del buffer habilitado con enable, entonces ahora pensando que tenemos un almacen de textos en memoria, lo que nos queda es recuperarlo de ese almacen, y si alguna vez se te dá por leer los manuales de PL/SQL, vas a ver que el package dbms_output tiene varias rutinas, entre ellas el bendito get_line(), quien se encarga de obtener ese texto del buffer! Entonces ahora sí estoy en condiciones de utilizar el dbms_output desde Pro*C! Acá va el ejemplo:
exec sql begin declare section;
varchar vcTexto[40000];
short indTexto;
int iStat;
short indStat;
exec sql end declare section;
...
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.enable(null);
dbms_output.put_line('Hola mundo desde PL/SQL');
dbms_output.get_line(:vcTexto:indTexto, :iStat:indStat);
end;
end-exec;
if(indTexto==0) printf("%s\n", vcTexto.arr);
Otro ejemplo (en este recupero el texto en otro bloque, pero como la sesion es la misma, el buffer prevalece y por ende su contenido):
exec sql begin declare section;
varchar vcTexto[40000];
short indTexto;
int iStat;
short indStat;
exec sql end declare section;
...
exec sql execute
begin
dbms_output.enable(null);
dbms_output.put_line('Hola mundo desde PL/SQL');
end-exec;
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.get_line(:vcTexto:indTexto, :iStat:indStat);
end;
end-exec;
if(indTexto==0) printf("%s\n", vcTexto.arr);
Tercer y último ejemplo:
Dentro de una rutina almacenada, lo lleno de mensajes en todas las posibles salidas de error/exception.
SQL> create or replace procedure Quique is
2 begin
3 FOR i IN 1..100 LOOP
4 dbms_output.put_line(RPAD('*',1000,'*'));
5 END LOOP;
6 end;
7 /
Procedure created.
SQL>
e invoco la rutina desde el Pro*C, de esta forma:
exec sql begin declare section;
varchar vcTexto[40000];
short indTexto;
int iStat;
short indStat;
exec sql end declare section;
...
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.enable(null);
Quique;
end;
end-exec;
while(iStat==0) {
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.get_line(:vcTexto:indTexto, :iStat:indStat);
end;
end-exec;
if(indStat<0) istat = 1;
if(indTexto==0)
printf("%s\n", vcTexto.arr);
}
Cuando el buffer quede vacío, iStat contendrá el valor uno.
Cómo dice el manual, hay que declarar una variable huesped de tipo varchar no inferior a 32767, de lo contrario emitirá el error ora-6502.
Ojo! Si entre lecturas del buffer con get_line, se invoca un put_line, éste vacía el buffer con lo cual se pierde el resto de las lecturas previas al put_line.
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_output.htm#BABGBACJ
Nosotros estamos acostumbrados a sacar mensajes desde un PL/SQL siempre y cuando usemos el sqlplus:
$ sqlplus ***/***
SQL> set serveroutput on; <=== para que se vean los mensajes que mostremos con el dbms_output
SQL> begin
2 dbms_output.enable(null); <=== para habilitar un buffer sin límites
3 dbms_output.put_line('Hola Quique'); <=== "muestra el texto por pantalla" (nótese las comillas)
4 end;
5 / hola PL/SQL procedure successfully completed.
SQL>
Ahora, la incognita errónea que siempre nos preguntamos o al menos yo lo hice es, cómo implementamos la instrucción "set serveroutput on" desde Pro*C, si este es un comando de sqlplus? Y ete aquí que lo que está mal formulada es la pregunta o el concepto del put_line. put_line no muestra un texto, sino que pone un texto dentro del buffer habilitado con enable, entonces ahora pensando que tenemos un almacen de textos en memoria, lo que nos queda es recuperarlo de ese almacen, y si alguna vez se te dá por leer los manuales de PL/SQL, vas a ver que el package dbms_output tiene varias rutinas, entre ellas el bendito get_line(), quien se encarga de obtener ese texto del buffer! Entonces ahora sí estoy en condiciones de utilizar el dbms_output desde Pro*C! Acá va el ejemplo:
exec sql begin declare section;
varchar vcTexto[40000];
short indTexto;
int iStat;
short indStat;
exec sql end declare section;
...
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.enable(null);
dbms_output.put_line('Hola mundo desde PL/SQL');
dbms_output.get_line(:vcTexto:indTexto, :iStat:indStat);
end;
end-exec;
if(indTexto==0) printf("%s\n", vcTexto.arr);
Otro ejemplo (en este recupero el texto en otro bloque, pero como la sesion es la misma, el buffer prevalece y por ende su contenido):
exec sql begin declare section;
varchar vcTexto[40000];
short indTexto;
int iStat;
short indStat;
exec sql end declare section;
...
exec sql execute
begin
dbms_output.enable(null);
dbms_output.put_line('Hola mundo desde PL/SQL');
end-exec;
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.get_line(:vcTexto:indTexto, :iStat:indStat);
end;
end-exec;
if(indTexto==0) printf("%s\n", vcTexto.arr);
Tercer y último ejemplo:
Dentro de una rutina almacenada, lo lleno de mensajes en todas las posibles salidas de error/exception.
SQL> create or replace procedure Quique is
2 begin
3 FOR i IN 1..100 LOOP
4 dbms_output.put_line(RPAD('*',1000,'*'));
5 END LOOP;
6 end;
7 /
Procedure created.
SQL>
e invoco la rutina desde el Pro*C, de esta forma:
exec sql begin declare section;
varchar vcTexto[40000];
short indTexto;
int iStat;
short indStat;
exec sql end declare section;
...
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.enable(null);
Quique;
end;
end-exec;
while(iStat==0) {
memset(&vcTexto, (int)NULL, sizeof(vcTexto));
exec sql execute
begin
dbms_output.get_line(:vcTexto:indTexto, :iStat:indStat);
end;
end-exec;
if(indStat<0) istat = 1;
if(indTexto==0)
printf("%s\n", vcTexto.arr);
}
Cuando el buffer quede vacío, iStat contendrá el valor uno.
Cómo dice el manual, hay que declarar una variable huesped de tipo varchar no inferior a 32767, de lo contrario emitirá el error ora-6502.
Ojo! Si entre lecturas del buffer con get_line, se invoca un put_line, éste vacía el buffer con lo cual se pierde el resto de las lecturas previas al put_line.
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_output.htm#BABGBACJ
lunes, 13 de julio de 2009
ORACLE: dbca & netca no arrancan...
...googleando encontré la respuesta!
Agregando esta línea al listener.ora se solucionó mi problema:
(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST=hostname)(PORT = 1521))
Anteriormente, lo solucionaba renombrando el archivo, y restaurándolo posteriormente a haber utilizado alguno de los asistentes.
Queda pendiente conocer la causa de este problema!
Agregando esta línea al listener.ora se solucionó mi problema:
(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST=hostname)(PORT = 1521))
Anteriormente, lo solucionaba renombrando el archivo, y restaurándolo posteriormente a haber utilizado alguno de los asistentes.
Queda pendiente conocer la causa de este problema!
ORACLE: Creando una instancia de base de datos a mano.
Siempre es más sencillo y rápido utilizar el asistente (dbca) para contruir una instancia de base de datos, pero a su vez comienza a crecer la incertidumbre de "qué es lo que está haciendo por atrás". Entonces, me tomé el tiempo de seguir el instructivo de los propios manuales de Oracle en inglés, y me lancé a contruirla manualmente. Aunque como dije están los manuales de Oracle explicando paso a paso como hacerlo, lo está en inglés, así que para facilitarles un poco la vida a los hispanoparlantes como yo, voy a intentar aclarar un poco cuales son estos pasos.
- Especificar a través de la variable de ambiente ORACLE_SID el nombre de la instancia que vamos a construir. En mi caso, export ORACLE_SID=xyz
- Asegurarse de que las variables de ambiente requeridas por Oracle, se encuentren definidas: ORACLE_SID, ORACLE_HOME y que la variable PATH contenga a $ORACLE_HOME/bin.
(Paso: 2)
- Es MUY IMPORTANTE seleccionar el método de autenticación para el/los administradores. Existen dos alternativas: archivos de contraseñas y a través del sistema operativo. En mi caso, utilicé el archivo de contraseñas. Este archivo lo generé con el comando orapwd, posicionado en el directorio dbs. Sin este archivo, los usuarios privilegiados como SYS, no pueden conectarse a través de TNS.
(Paso: 3)
(ANEXO: pasos para construir el archivo de contraseñas)
- Construir el archivo de parámetros de inicialización (init.ora). Se puede utilizar una plantilla que se encuentra ubicada en $ORACLE_HOME/dbs/init.ora. Se copia y se parametriza a gusto. Cada uno de los parámetros se puede visualizar en este manual de referencia.
(Paso: 4)
- Conectarse a lo que va a ser nuestra nueva instancia de base de datos. Estando conectado con el usuario unix propietario del software de base de datos, se puede conectar usando "sqlplus / as sysdba".
(Paso: 6 (el 5to paso lo obvié, porque es para bases en windows.))
- Una vez conectados, procedemos a construir el archivo de parámetros del servidor. Esto lo hacemos con la instrucción "create spfile from pfile='/.../initxyz.ora';", reemplazando [...] por la ruta absoluta donde se encuentra nuestra copia.
(Paso: 7)
- Arrancamos la instancia, sin montar la base con la instrucción: "startup nomount".
(Paso: 8)
- Construir la configuración de base de datos, con la instrucción "create database ...". En la descripción en inglés se muestra un ejemplo de la instrucción.
(Paso: 9)
- Construir el diccionario de base de datos. En el directorio $ORACLE_HOME/rdbms/admin se encuentran los script de administración, entre ellos hay que ejecutar dos: catalog.sql y catproc.sql
(Paso: 11 (el paso 10, habla sobre como contruir tablespaces adicionales.))
Repito: si quieren conectarse de esta forma: "sqlplus sys/pass@tns as sysdba" deberán tener generado el archivo de contraseñas!
Cualquier tipo de feedback sobre este artículo o cualquiera de los otros, será bienvenido.
miércoles, 10 de junio de 2009
ORACLE: Instalación del cliente Oracle 10.2.0.1 sobre Fedora 9 de 64 bits
Prerequisitos:
yum install libXp-1.0.0-11.fc9.i386
yum install libXt-1.0.4-5.fc9.i386
yum install libXtst-1.0.3-3.fc9.i386
export ORACLE_HOME=$ORACLE_BASE/product/10.2.0.1
Editar el archivo redhat-release con el siguiente contenido:
redhat release 4
Descargar el instalador desde el sitio de OTN.
Descomprimirlo: gunzip 10201_client_linux_x86_64.cpio.gz
Desempaquetarlo: cpio -idmv < 10201_client_linux_x86_64.cpio
Iniciar la instalación con el usuario oracle de unix:
./runInstaller &
yum install libXp-1.0.0-11.fc9.i386
yum install libXt-1.0.4-5.fc9.i386
yum install libXtst-1.0.3-3.fc9.i386
export ORACLE_HOME=$ORACLE_BASE/product/10.2.0.1
Editar el archivo redhat-release con el siguiente contenido:
redhat release 4
Descargar el instalador desde el sitio de OTN.
Descomprimirlo: gunzip 10201_client_linux_x86_64.cpio.gz
Desempaquetarlo: cpio -idmv < 10201_client_linux_x86_64.cpio
Iniciar la instalación con el usuario oracle de unix:
./runInstaller &
viernes, 5 de junio de 2009
LINUX: Kernel
Pasaron mil años desde el último kernel que compilé, creo que fué allá por la versión 2.0.x, cuando aún contaban con opciones limitadas, a diferencia de las millones de opciones con las que cuenta ahora. Pero llegó el momento de embarrarme nuevamente, y construir un kernel a la medida de mis necesidades.
ADVERTENCIA: Niños no hagan esto sin la supervisión de un adulto.
La plataforma de mis pruebas fué el servidor Linux / Fedora 9 de desarrollo de la consultora, jejeje. Gracias a Dios, Alá, Buda, todo resultó bien, y aún no me despidieron!
Este Fedora estaba utilizando el kernel 2.6.25 de 64 bits, y lo que hice fué actualizarlo al 2.6.28.
Acá voy a registrar la bitácora de mi trabajo, y no estoy escribiendo un manual para compilar un kernel, para ello ya hay varios distribuídos en la web y escrito por gente experta.
Los pasos desde aquella versión a la 2.6 practicamente, no cambiaron.
make mrproper
make clean
make menuconfig (si es que sabes de que se trata cada abreviatura de las opciones)
make xconfig (si queres un entorno visual, y con una mayor explicación de qué se trata cada opción, inclusive hasta te recomienda por qué optar!)
make dep
make
make modules
make modules_install
make install
Como se puede apreciar, primero instalé los módulos y luego el kernel, si lo hacía al revés cuando intentaba instalar el kernel detectaba una falta de símbolos, y dejaba el kernel a "medio instalar".
Es recomendable, agregarle un texto a la versión del kernel (opción: General Setup / Local Version). Este texto podrá visualizarse posteriormente con el comando: uname -r
Por otra parte, la instrucción "make modules_install", creará un directorio usando el texto como sufijo.
Por ejemplo: si "local version" lo configuramos con el texto "-test", el comando "uname -r" mostrará: 2.6.28-test, tanto el kernel, el system.map y el initrd.img tendrán este sufijo, al igual que el directorio de modulos: /lib/modules/2.6.28-test/
También hay que tener en cuenta de copiar la configuración (make xconfig) de compilación del kernel, esta configuración queda almacenada en el archivo .config en la raíz donde se encuentra los fuentes del kernel: "cp -i /usr/src/kernel/linux-2.6.28/.config /boot/config-2.6.28-test"
La regla menuconfig, es util cuando estamos trabajando en una terminal en modo texto, aparentemente utiliza los menú de dialog.
La regla xmenu, abre un menú visual usando las QT sobre X-Window.
La regla gmenu, es igual que la anterior, pero utilizando las GTK sobre X-Window.
La regla install, hasta me configuró el gestor de arranque grub, y yo creo que por cuestiones de seguridad, no pone la nueva entrada, como opción por defecto.
La regla mrproper, se supone que hasta inicializa el archivo .config a diferencia del clean que no lo hace, googleando me encontré que mrproper, era el nombre de un producto de limpieza europeo Mr. Proper, qué curioso, no?
ADVERTENCIA: Niños no hagan esto sin la supervisión de un adulto.
La plataforma de mis pruebas fué el servidor Linux / Fedora 9 de desarrollo de la consultora, jejeje. Gracias a Dios, Alá, Buda, todo resultó bien, y aún no me despidieron!
Este Fedora estaba utilizando el kernel 2.6.25 de 64 bits, y lo que hice fué actualizarlo al 2.6.28.
Acá voy a registrar la bitácora de mi trabajo, y no estoy escribiendo un manual para compilar un kernel, para ello ya hay varios distribuídos en la web y escrito por gente experta.
Los pasos desde aquella versión a la 2.6 practicamente, no cambiaron.
make mrproper
make clean
make menuconfig (si es que sabes de que se trata cada abreviatura de las opciones)
make xconfig (si queres un entorno visual, y con una mayor explicación de qué se trata cada opción, inclusive hasta te recomienda por qué optar!)
make dep
make
make modules
make modules_install
make install
Como se puede apreciar, primero instalé los módulos y luego el kernel, si lo hacía al revés cuando intentaba instalar el kernel detectaba una falta de símbolos, y dejaba el kernel a "medio instalar".
Es recomendable, agregarle un texto a la versión del kernel (opción: General Setup / Local Version). Este texto podrá visualizarse posteriormente con el comando: uname -r
Por otra parte, la instrucción "make modules_install", creará un directorio usando el texto como sufijo.
Por ejemplo: si "local version" lo configuramos con el texto "-test", el comando "uname -r" mostrará: 2.6.28-test, tanto el kernel, el system.map y el initrd.img tendrán este sufijo, al igual que el directorio de modulos: /lib/modules/2.6.28-test/
También hay que tener en cuenta de copiar la configuración (make xconfig) de compilación del kernel, esta configuración queda almacenada en el archivo .config en la raíz donde se encuentra los fuentes del kernel: "cp -i /usr/src/kernel/linux-2.6.28/.config /boot/config-2.6.28-test"
La regla menuconfig, es util cuando estamos trabajando en una terminal en modo texto, aparentemente utiliza los menú de dialog.
La regla xmenu, abre un menú visual usando las QT sobre X-Window.
La regla gmenu, es igual que la anterior, pero utilizando las GTK sobre X-Window.
La regla install, hasta me configuró el gestor de arranque grub, y yo creo que por cuestiones de seguridad, no pone la nueva entrada, como opción por defecto.
La regla mrproper, se supone que hasta inicializa el archivo .config a diferencia del clean que no lo hace, googleando me encontré que mrproper, era el nombre de un producto de limpieza europeo Mr. Proper, qué curioso, no?
lunes, 4 de mayo de 2009
LINUX: iptables (bitácora)
Llegó el momento de proteger un poco el servidor, y qué mejor que arrancar aprendiendo un poco de iptables. Aún mantengo el firewall sin reglas, solo me dedico a monitorear que es lo que está llegando al equipo, para no poner barreras de más y dejar sin conexión a algún cristiano que acceda al mismo. Para eso, arranco jugando con la generación de bitácoras. Primero le digo a rsyslogd qué mensajes quiero guardar y donde hacerlo, agregando esta línea al archivo /etc/rsyslog.conf:
- kern.warn /var/log/iptables.log
Luego para que el cambio surta efecto, reinicio el demonio de rsyslog:
- /etc/init.d/rsyslog restart
Ahora sí manos a la obra con el "misterioso, para mí" iptables, le damos la primer instrucción:
- iptables -A INPUT -i eth0 -j LOG --log-level warn
En mi caso, filtré todo lo que venga por la primer interfaz ethernet. Ahora, todo lo que esté llegando por esa interfaz quedará registrado en el archivo /var/log/iptables.log
A mí se me hizo bastante útil este tipo de monitoreo, antes de empezar a cerrar todo el equipo, espero a alguien más también le sirva.
Qué os disfrutéis!
Suscribirse a:
Entradas (Atom)