Oracle 10g: Suche Tätigkeit "außerordentliche" in unserer Datenbank

Druckversion

 

Al administrar nuestra base de datos tenemos que lidiar a veces con aplicaciones de terceros(ERPs, etc...) o desarrolladas dentro de la empresa que a veces pueden tener mal planteados algunos procesos o por el motivo que sea traten la base de datos como si fuera exclusivamente suya. Voy a mostraros un ejemplo:

Entorno:
-servidor con dos puntos de montaje. El del sistema operativo donde también residen los archivos de datos de la base de datos y un disco secundario donde tenemos los archivos de copia rman más los archivelogs.

-base de datos Oracle10g funcionando en modo archivelog.
-política de retención de copias de 3 días y 60 archive logs al día de media.

Sintoma:
-Nos quedamos sin espacio donde metemos los backups de la base de datos debido al crecimiento de la generación de más archivelogs de la cuenta.

Detectar la causa:
Si tenemos bien dimensionada la política de retención de backups pero de repente en nuestra base de datos se estan generando más archivelogs de la cuenta puede ser debido a una acividad "extra-ordinaria" en la base de datos. Para detectarla primero podemos consultar el número de ficheros que se generan por hora consultando la tabla v$log_history:

select to_char(FIRST_TIME,'DY, DD-MON-YYYY') day,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'00',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'00',1,0))) d_0,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'01',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'01',1,0))) d_1,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'02',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'02',1,0))) d_2,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'03',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'03',1,0))) d_3,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'04',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'04',1,0))) d_4,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'05',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'05',1,0))) d_5,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'06',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'06',1,0))) d_6,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'07',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'07',1,0))) d_7,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'08',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'08',1,0))) d_5,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'09',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'09',1,0))) d_9,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'10',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'10',1,0))) d_10,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'11',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'11',1,0))) d_11,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'12',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'12',1,0))) d_12,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'13',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'13',1,0))) d_13,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'14',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'14',1,0))) d_14,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'15',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'15',1,0))) d_15,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'16',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'16',1,0))) d_16,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'17',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'17',1,0))) d_17,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'18',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'18',1,0))) d_18,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'19',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'19',1,0))) d_19,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'20',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'20',1,0))) d_20,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'21',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'21',1,0))) d_21,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'22',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'22',1,0))) d_22,
       decode(sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'23',1,0)),0,'-',sum(decode(substr(to_char(FIRST_TIME,'HH24'),1,2),'23',1,0))) d_23,
       count(trunc(FIRST_TIME)) Total
 from v$log_history
 group by to_char(FIRST_TIME,'DY, DD-MON-YYYY')
 order by to_date(substr(to_char(FIRST_TIME,'DY, DD-MON-YYYY'),5,15) )

 

(RESULTADO DE EJEMPLO)

Con esto ya vemos que hay un pico el lunes 1 de julio desde horas "intempestivas" hasta las 10:00 de la mañana. Si queremos informarnos más antes de hablar con los responsables podemos consultar la v$sqlarea para detectar consultar repetitivas y pesadas para conocer el sql, número de ejecucuciones, coste , etc... Una consulta ejemplo seria la siguiente:

SELECT sql_text "Sql",
         executions "Ejecuciones",       
         ceil(cpu_time/greatest(executions,1)) "Avg Cpu",
         ceil(elapsed_time/greatest(executions,1)) "Avg Disk",
         ceil(elapsed_time/greatest(executions,1)) "Avg Time"
  FROM v$sqlarea
  ORDER BY ceil(elapsed_time/greatest(executions,1)) desc,
           ceil(cpu_time/greatest(executions,1)) desc,
           ceil(disk_reads/greatest(executions,1)) desc;

De esta manera conoces la tabla que se está "populando" de forma masiva y puedes preguntar al desarrollador cubriendote la espalda de antemano ya que no siempre le conocemos, le tenemos confianza o simplemente sabemos que nos acabará ocultando lo que ha hecho... o peor aún NO SABE LO QUE ESTÁ HACIENDO!!
 

 

Citius!, Altius!, Fortius! (Schneller, Höher, Stärker). Das Motto der Olympischen Spiele hilft uns zum Nachdenken über unsere geschäftlichen Ziele zu diesem Zeitpunkt. Weil wir bekennen, die wir in Zeiten des Wandels exponentiellen Vertriebszyklen variieren leben, ist der Markt aggressiver, sich wandelnden Konsummuster, bevor sie analysiert Verkäufe abzuschließen. Wir müssen weiter gehen,...
Die Millionen-Dollar-Frage .. Weiß oder Schwarz? Huhn und Ei? Die Leute von LinuxJournal hat einen Artikel für Abonnenten (oder bis zum nächsten Monat warten), auf der Datenbank nach Dinge / Fällen verwendet werden sollten freigegeben. Bond, hier
Eine Oracle-Datenbank im Standby ist eine exakte Kopie eines operativen Datenbank auf einem Remote-Server als Backup verwendet, und kopieren Sie als Referenz, Disaster Recovery, etc.. Eine Datenbank im Standby-Modus ist mehr als eine normale Sicherung und das kann in die Produktion Katastrophe in kürzerer Zeit als hätten wir ein Backup zurückspielen (entweder von der einfachen rman oder Export...