Hasta lo poco que me concierne, no es posible crear triggers en vistas  del esquema SYS  sugeri la creacion de una copia a v$session por si ibas a trabajar sobre otro usuario y no SYSTEM. Tambien recuerda que las vistas reflejan todo en tiempo real, no es una tabla estatica que no se actualiza al menos que intervenga manos humanas.

Podrias crear tu evento con DBMS_SCHEDULER que se reproduzca cada 60 segundos (1 minuto) y llame los datos en ese tiempo y te vaya haciendo un log spool en un archivo fisico, o en una tabla o donde gustes de todo lo que ocurra cada 60 segundos sobre los campos que te interesan de v$session. (Pero esto no seria en tiempo real) sino cada 60 segundos.

De hecho hice una mini-prueba en mi Oracle  

 
SQL> CREATE VIEW ejemplo AS SELECT command, USER#, username, STATUS, logon_time FROM v$session;
 
VIEW created.
 
SQL> SELECT * FROM ejemplo;
 
   COMMAND      USER# USERNAME                       STATUS   LOGON_TIM
---------- ---------- ------------------------------ -------- ---------
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         3          0 SYS                            ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
 
   COMMAND      USER# USERNAME                       STATUS   LOGON_TIM
---------- ---------- ------------------------------ -------- ---------
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
 
18 ROWS selected.
 
SQL> CREATE USER pepe IDENTIFIED BY pepe;
 
USER created.
 
SQL> GRANT CONNECT, resource TO pepe;
 
GRANT succeeded.
 
SQL> GRANT SELECT, INSERT, UPDATE ON SYS.EJEMPLO TO pepe;
 
GRANT succeeded.
 
SQL> exit
 
oracle@marian:~$ sqlplus pepe/pepe                                                    
 
SQL*Plus: Release 10.2.0.1.0 - Production ON Thu Nov 5 15:39:45 2009
 
Copyright (c) 1982, 2005, Oracle.  ALL rights reserved.
 
 
Connected TO:
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.1.0 - Production
WITH the Partitioning, OLAP AND DATA Mining options                   
 
SQL> SELECT * FROM SYS.EJEMPLO;
 
   COMMAND      USER# USERNAME                       STATUS   LOGON_TIM
---------- ---------- ------------------------------ -------- ---------
         0          0                                ACTIVE   05-NOV-09
         3         60 PEPE                           ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         3          0 SYS                            ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
 
   COMMAND      USER# USERNAME                       STATUS   LOGON_TIM
---------- ---------- ------------------------------ -------- ---------
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
         0          0                                ACTIVE   05-NOV-09
 
19 ROWS selected.
 
 
 
 

Te podria servir... nunca se sabe  

No puedo afirmartelo lo siento.

Pero porque no creas una vista copia de v$session solo con los campos que deseas obtener ver? y dicha vista otorgale permisos a X usuario para que este usuario cree un procedimiento almacenado (si es requerido) para ver dichos datos llamando los campos de esa vista nueva?

Ahhhhhhhh pero yo pensaba que era que en tu clase los profesores te habian exhigido que no podias crear un TRIGGER sobre esta vista    por eso sugeri lo del evento, olvidalo.

Prueba lo siguiente:

 
CREATE OR REPLACE TRIGGER trigo
  AFTER LOGON ON DATABASE
DECLARE
  v_prog sys.v_$session.program%TYPE;
BEGIN
   /* Tu codigo Aqui */
END;
/
 
 

No me digas tampoco te explicaron sobre los TRIGGERS de sistemas y sus condiciones en Oracle???? (No estoy ya empapada del tema, hace unos meses abandone el PL/SQL en Oracle) Pero esto te puede ayudar, para crear TRIGGERS sobre vistas de SYSTEM.

http://www.psoug.org/reference/system_trigger.html

Tambien existe la posibilidad de que hagas otra vista de la vista v$session solamente con los campos que te interesan ver de v$session y crear un usuario con los roles que le permitan ver dicha vista en su entorno, y asi captar en tiempo real todos los cambios que requieras obtener.  Y puedes crear tu Stored Procedure llamando los datos de esta vista nueva que usa de referencia a v$session y mostrar en OUTPUT los resultados obtenidos    ya sabes que a tu ST puedes concatenarle la fecha actual con current_date();

Suerte con eso

No se si serviria дٳŦ٭      MySQL guarda sus datos en la cache de memoria en tiempo real (digase intenta aprovechar la cache al maximo) en vez de ir guardando todo en disco duro. Aunque al finalizar la sección al tener el AUTOCOMMIT por defecto habilitado se guarda la data he indices en el correspondiente tablespace. 

Si el no hubiese reiniciado el motor, hubiese podido recuperar la estructura de las tablas junto a la data he indices (Aun solo con los archivos *.frm disponibles) hubiera hecho lo que le sugeri, hubiera recuperado todo desde la cache de memoria y hubiera podido aprovechar y hacer un dumpeo de esa data completa antes de reiniciar el motor (Ya que al reiniciarlo todo se hubiera limpiado de la cache como le sucedio) pero ya con un dumpeo logico de la DB restaurarlo era lo mas sencillo.

Ojala encuentres un recuperador de archivos efectivo, pero no se hasta que nivel podria servirte en recuperacion, ojala puedas resolver tu problema sin mucho esfuerzo.

La tienes un pelin dificil    lo mas cercano que se me podria ocurrir (Ya que no puedes usar triggers y la verdad un bucle    no quisiera saber cuanto afectaria esto a la lectura de disco). Puedes intentar con un Evento? un Evento que se ejecute cada 60 segundos (1 minuto) y consulte la vista V$SESSION para obtener eso que solicitas... Ya con dicho evento podrias llamar tu procedimiento almacenado acorde a que se cumpla o no algo, lo negativo de los eventos que no es en tiempo real (Como un trigger) pero mejor que lea cada 60 segundos y no que lea cada segundo como haria un Bucle. Si te interesa sobre eventos en Oracle investigate sobre:

DBMS_SCHEDULER

  

Ahh pos mira que bien, cuando te referias a 1 Textbox asumi que te referias a que solo se insertaba 1 solo apellido y no los dos juntos....

Aunque literalmente usando LIKE %Lopez Ruiz%  funcione, yo habia asumido que era1 solo apellido %Lopez%  pero si tu textbox accepta los 2 campos, yo me inclinaria mas por el array, los 2 parametros y el

WHERE Apellido_Paterno = parametro1 OR Apellido_materno = parametro2 
La razon? optimizacion  (solo si los 2 campos anteriores son indices) ya que la clausula LIKE filtra en todos los registros existentes y inexistente (NULL) de la tabla y si yo tengo 5 millones de registros.... ya tomas la idea.

Pero si prefieres mantenerte con el LIKE ni modo

Lo siento mucho la verdad      

Te habia dicho que no se podia (porque realmente no se puede con lo que dispones) pero luego pense que si tu servidor era un hosting compartido o asi, posiblemente no habias o no se habia reiniciado el motor, por lo que si, existia la posibilidad de recuperar todo con los archivitos *.frm nada mas.... (Ya que la info el motor lo hubiese llamado desde la memoria cache  ) Pero si tu mismo me confirmas que reiniciaste el motor, lo siento ya si que no hay en absoluto nada que puedas hacer          me hubiese gustado ayudarte, pero no te dire mentira no es posible solo con los archivitos *.frm y un motor reiniciado     Si al menos hubieras tenido un backup logico de esas tablas algo hubieras podido recuperar.

No veo en que la clausula LIKE busque por los 2 apellidos     
Que pasa si el apellido paterno es Lopez y el Materno es Ruiz y tu estas buscando en base a 1 solo Apellido en este caso Lopez asi:

%Lopez%

Eso es traeme todos los apellidos que tengan en su centro la palabra 'Lopez'...

So no te entiendo

Perdona, se me olvido aclararte mi sugerencia para recuperar tablas y sus registros con archivos *.frm solo aplica siempre y cuando no se haya reiniciado o hecho flush a la metadata del motor MySQL    si por X o Y razon, reiniciaron el servidor o el motor de la DB despues que te ocurrio ese problemon que llevas... me temo que se perdio toda la data de la cache en memoria por ende, no podras recuperar nisiquiera la estructura de las tablas que se guardan en los *.frm      

Lo que te pego el-brujo y lo que te especifique mas arriba involucra el mismo tema (No hay forma de recuperar nisiquiera la estructura de una tabla en base solo a archivos *.frm),  la sugerencia que te di aplica porque llama toda la info de la cache de memoria, pero si reiniciaste el motor de base de datos o el servidor Linux... me temo que no hay nada que puedas hacer. Ya te lo expuse mas arriba y mira que han vuelto a postearte la notificacion.