Suplantar usuarios

Hoy vamos a hablar de ese momento en el que tenemos de toquetear objetos de otro usuario, bien porque nadie tiene el password de ese usuario (si es que son...) , bien porque queremos comprobar que ese usuario puede hacer eso que nosotros decimos que puede hacer y el asegura que no , o bien por oscuras intenciones... :-{


En Oracle tenemos la siguiente sentencia:

ALTER SESSION SET CURRENT_SCHEMA=SCOTT;


Aunque esto nos es útil para toquetear sus objetos sin necesidad de estar poniendo siempre el

SCOTT.OBJETO

no nos será útil para comprobar que ese privilegio que le hemos concedido a un usuario esté funcionando correctamente, ya que en realidad continuamos siendo el mismo usuario:




SQL> conn / as sysdba

SQL> alter session set CURRENT_SCHEMA=SCOTT;

Sesi�n modificada.

SQL> select user from dual;

USER
------------------------------
SYS



En Sybase tenemos el comando setuser, ahora mismo no dispongo de un gestor Sybase a mano, pero puedo decir que este comando es más potente que el comando de Oracle, ya que realmente estás suplantando al usuario, pudiendo por ejemplo dar permisos sobre objetos del usuario suplantado.



Y por último, la suplantación definitiva!!!!!
Lo vamos a probar con Oracle, pero seguro que también se puede hacer en Sybase.
Este método sólo es para utilizarlo en situaciones extremas, y por el bien de la humanidad, nunca para hacer el mal.
Ahí vamos:

-Primero miramos el password encriptado del usuario


SQL> select username, password from dba_users where username='SCOTT';

USERNAME PASSWORD
------------------------------ ------------------------------
SCOTT F894844C34402B67


-Cambiamos el password del usuario SCOTT


SQL> alter user SCOTT identified by lion;

Usuario modificado.


-Nos conectamos con el nuevo password y hacemos lo que tengamos que hacer


SQL> conn scott/lion
Conectado.
SQL> select * from dept;

DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON


-Luego restauramos el password antiguo

SQL> conn / as sysdba
Conectado.
SQL> alter user scott identified by values 'F894844C34402B67';

-Y ya está.

SQL> conn scott/tiger;
Conectado.




Esto, como ya he dicho puede ser utilizado para hacer cosas muy feas, pero también nos puede ser útil por ejemplo en esa aplicación antigua que ya nadie sabe como funciona, y nadie se atreve a tocar, como la aplicación se conencta con un usuario del que nadie sabe el password no podemos modificarlo, pero si necesitamos entrar con este usuario, siempre podemos hacer esto.


Hasta lueg

Una de parámetros en las estadísticas

Hoy toca ración doble, y además un mail de Óscar, no se prodiga mucho pero lo que envía es muy interesante, muy recomendable la lectura del link que nos pasa.

Por cierto, probablemente cuando vuelva a leer lo que voy a escribir me darán ganas de llorrar, pero bueno,

le vamos a meter 4 al Mánchester (o no)!!!



Después de desvariar un poco, aquí va lo de las estadísticas:



"
Este tío ha hecho un comentario muy interesante sobre un tema de parámetros específicos en el paquete estrella que actualiza estadísticas en oracle.

Oracle no reconoce públicamente este error, pero yo también lo corroboro.



Comprobarlo y guardarlo en vuestro kit de supervivencia:



http://davidpujol.blogspot.com/2007/09/estadsticas-qu-mtodo-utilizar.html


Óscar
"

Top 10 CPU queries en Oracle

Hoy una nueva colaboración de Xavi, voy tirando de correos antiguos, aun me qudan unos cuantos. El título lo dice todo, así que os pongo el cut&paste y palante.

"Hola de nuevo,

He medio montado esta query que me parece muy útil. Extrae las 10 consultas que más cpu han consumido en una instancia oracle desde que ésta está arriba. Con una simple modificación, se puede usar también para sacar las que usan más accesos a la caché y otras.

select * from (

select distinct sql_text, round(cpu_time/executions)/1000000 cpu_time_sec_per_exec, sharable_mem, persistent_mem,

runtime_mem, executions, cast ((parse_calls/executions) as number (10,0)) parse_call_per_exec, cast((sorts/executions) as number (10,2)) sorts_per_exec,

cast ((buffer_gets/executions) as number(10,0)) buffer_gets_per_exec , cast((disk_reads/executions) as number(10,0)) disk_reads_per_exec, loads, open_versions,

to_char(to_date(first_load_time, 'YYYY-MM-DD/HH24:MI:SS'),'MM/DD HH24:MI:SS') first_load_time, rawtohex(address) address, hash_value hash_value, round(rows_processed/executions) rows_processed_per_exec,

command_type, parsing_user_id, OPTIMIZER_MODE

from v$sqlarea

where (parsing_user_id != 0)

and (executions >= 1000) order by cpu_time_sec_per_exec desc)

where rownum <=10

Con cambiar el order by puedes sacar las que tienen más buffer gets, las que acceden más a disco, etc. Esta consulta está para 9i, pero en 10g se pueden sacar aún más datos (mirad la vista v$sqlarea).

Con esta vista lo más importante a tener en cuenta es que algunos datos son acumulativos, y otros no, y que, de los acumulados, unos nos interesan acumulados y otros no. Por eso hay que tratarla un poco.

En este caso he puesto executions >=1000 porque me interesaba sacar las consultas frecuentes que más consumen. Si se quiere sacar la que más ha consumido de todos los tiempos (desde que la instancia está arriba, claro) se ha de poner un 1. Esto depende del tipo de entorno que tengáis o de lo que busquéis.

Otra posibilidad a tener en cuenta es que si el entorno no usa bind variables (o no las usa bien), puede que todas las consultas que os ocupen el top ten sean variaciones de la misma (un select con diferentes condiciones de búsqueda). Ese caso se puede añadir substr(sql_text,1,50) (o el valor más apropiado para el caso) para eliminar las duplicaciones.

Si sospecháis que el problema no es el tipo de query, sino que hay una query que para un determinado valor se dispara el coste (por un tema de duplicaciones en índices, o que no entra por índice), se puede eliminar la cláusula distinct, pero en ese caso se tiene que añadir sql_text como condición con alguna cadena, esto es, hay que ir ya a la búsqueda de una determinada query y de cuánto consume. Si se lanza sin el distinct os pueden salir montones de queries iguales. Claro que siempre podéis lanzarla sin el rownum y leeros las cinco mil líneas, o más, que os saldrán a ver si encontráis algo interesante.

Xavi"

Oracle en Debian

Venga va una nueva entrada.
Hoy vamos a hablar de línux y oracle. En un principio Oracle Database está hecho para que funcione sobre Suse y Red Hat, aunque esto no es del todo cierto, ya que existe desde hace un par de años una versión "express edition" para Debian, algún día igual podemos hacer "apt-get install oracle" y la mitad de los dba's nos vamos a la puta calle :-S

http://www.oracle.com/technology/software/products/database/xe/htdocs/102xelinsoft.html



Cuando decía "Oracle Database está hecho para...", básicamente me refería a que (aparte de temas de soporte y otras mandangas), en los únicos sistemas en un principio en los que podrás hacer ./runInstaller, y te saldrá la ventanita java del instalador son Red Hat y Suse.
Pero tranquilos si queremos instalarlo en otro sistema operativo con pingüinos, no tendremos que hacer un curso de ingeniería avanzada. Simplemente habremos de cumplir todos los requisitos que se le piden a cualquier otro s.o., y una vez comprobado esto, como no podremos cumplir el requisito del sistema operativo haremos lo siguiente:


./runInstaller -ignoreSysPrereqs



Nos hemos roto eh?
Bueno aparte de esto hemos de tener installadas unas cuantas librerías, y algún pequqño error no documentado que va apareciendo lo subsanamos con una visita al metalink.
Venga os paso un link donde sale la checklist para instalar una 10g en Debian, la 11g es igual, y si no soys tan vagos como yo y llegáis a la segunda página del google seguro que encontráis una checklist.


http://www.1x4x9.info/files/oracledebian/html/online-chunked/



Venga hasta luego

Buenas a todos y a ver que pasa (tiempo de ejecución de una query)

Nada que este blog se creó hace tiempo pero no ha arrancado, vamos a ver si de aquí 6 meses ya he creado el segundo post.
De qué va este blog? Pues no lo tengo muy claro, en un principio la idea és ir poniendo entradas sobre documentos, ideas, howtos, etc., sobre temas de la administración de sistemas, y en especial administración de bases de datos (BBDD que queda más guay).
Aquí va el primero, Xavi me lo envió por correo el otro día, tengo muchas más cosas suyas, y mucho más interesantes, pero ya las iré poniendo poco a poco.
Venga, aquí va, como mirar cuanto tarda una query lanzada por nosotros mismos:

"

En sqlplus se puede usar la opción:

Set timing on

Por ejemplo

SQL> set timing on

SQL> select sysdate from dual;

SYSDATE

--------

17/04/08

Elapsed: 00:00:00.29

Esto no funciona con Embarcadero, por ejemplo."