Si un accidente 12c Oracle no ha ocurrido a usted, sin embargo, que sin duda va a pasar con el tiempo. Cuando lo hace, no va a ser en un momento conveniente.

El problema es que la gente asume que porque tienen un sistema basado en Oracle, el problema debe ser con Oracle. Podría ser, pero usted no sabe por el momento. Oracle es simplemente un componente de un sistema mayor, y la causa raíz y solución no puede basarse-Oracle. Incluso si usted recibe un mensaje de error de base de datos Oracle, la causa puede ser algo fuera de Oracle.

Asegúrese de buscar en el sistema general de apoyo a la base de datos, no sólo la propia base de datos.

No reaccione al informe de problemas a nivel de la cara. Aplique una estructura, patrón repetible cuando aborden problemas. Este próximo estado de cuenta no se puede enfatizar lo suficiente: La suya es una profesión técnica, y le pagan para resolver problemas, no simplemente a reaccionar y la esperanza de una solución rápida.

Todo el mundo tiene una metodología de resolución de problemas a medida para su entorno único, pero el siguiente es un comienzo:

1. Identificar el problema real. Determinar y confirmar lo que está sucediendo en el sistema.
2. Realizar comprobaciones básicas del sistema. Compruebe el servidor, el entorno operativo, y la conectividad de los errores absolutos y degradación del rendimiento.
3. Realizar comprobaciones de bases de datos básicos. Confirme que la base de datos está en ejecución y ver si puede conectarse a ella.
4. Determine qué significan los mensajes de error.
5. Desarrollar una solución y aplicarla. Confirme que la corrección funciona y que no hay consecuencias no deseadas.

Con la experiencia y el tiempo, modificará estos pasos para su entorno. Dependiendo de la situación, puede procesar algunos pasos muy rápido - pero siguen siendo procesado, no omitir.

Antes de hacer nada para solucionar el problema percibido, lo que necesita saber cuál es el verdadero problema. No se puede adivinar o suponer. Es mucho mejor para tratar la causa real de un problema, no sólo los síntomas.

Las personas que informaron problemas se emocionan, se pierda los detalles clave, hacer suposiciones, ya menudo inexacto afirmar la naturaleza y la gravedad de un problema; eso es simplemente la naturaleza humana. Si usted piensa lo contrario, pida a cualquier policía o ER médico acerca de la calidad de los informes de los testigos iniciales que reciben. Esto se agrava en el trabajo de equipo, ya que muchas personas que están reportando problemas no son técnicos y no pueden articular sus problemas muy bien.

Es necesario determinar qué componente del sistema tiene el problema y lo que está sucediendo en concreto antes de poder desarrollar y aplicar una solución. Haga las siguientes preguntas:

• Qué: ¿Qué específicamente que está sucediendo? Haga que el paseo de usuario a través de lo que está haciendo cuando se produce el error. Trabajar directamente con los problemas que tiene la persona y controlar la emisión en tiempo real en lugar de obtener información de segunda o tercera mano. Obtén capturas de pantalla o los mensajes de error propios.
• Quién: ¿Quién está afectado? ¿Es uno o dos usuarios? ¿Es una subclasificación específico de usuarios? ¿Es todo el mundo? Además, es su producción, prueba o sistema de desarrollo? Nunca asuma que porque alguien se excita, debe ser la producción. Tratar de corregir la base de datos mal te dejará sonrojarse de vergüenza.
• Dónde: los usuarios se ven afectados repartidos en una amplia ubicación geográfica, o son en una ciudad o edificio específico?
• Cuándo: ¿Cuánto tiempo ha estado ocurriendo, y se le ha ocurrido antes? Además, ¿que sucede cada vez o sólo a veces? Si sucede sólo en ocasiones, profundizar en lo que se hace antes del error.
  
  Si sólo se produjo ya que un cambio reciente en el sistema (tal como un parche, una actualización o un reinicio), que puede ser una pista valiosa. La pregunta "¿Qué ha cambiado recientemente en el sistema?" Es un gran día para preguntar!
• ¿Qué tan malo: ¿Esto es una pérdida total del servicio donde la empresa se ​​detiene, o es sólo una molestia en un sistema de desarrollo de poco uso?

Después de hacer estas preguntas, usted debe saber lo que está pasando, que está sucediendo a, lo malo que es, y cuando empezó. Usted también debe tener una idea aproximada de lo subsistema o componentes para empezar a comprobar.

Mantener la cabeza fría para solucionar problemas calientes; ser metódico y trabajar de una manera lógica hasta que se solucione el problema (y confirmó que se fija). Otras personas pueden excitarse, subrayaron, o poco profesional, pero hay que mantener su ingenio y profesionalidad a medida que trabaja hacia una solución. No se deje intimidar por los usuarios o gestión airados de pie sobre su hombro.