Soporte profesional de pago disponible por separado

Servicios Urgentes de Recuperación

Cuando una base de datos Oracle o MySQL de producción está caída, cada escritura, reinicio o restauración incompleta puede reducir las opciones de recuperación. DBRECOVER ofrece triaje y asistencia profesional de pago para incidentes críticos de corrupción, borrado, backups, storage y recuperación sin copia de seguridad.

Contactar Soporte Urgente Herramienta Oracle Software MySQL Gratis
Checklist inicial
1. Detenga intentos repetidos de startup, repair y restore 2. Preserve datafiles, control files, redo, archived logs y backups 3. Clone el storage dañado antes de ejecutar herramientas riesgosas 4. Reúna alert logs, errores, versión, plataforma y lista de archivos 5. Defina la vía más segura: restore, extracción, reconstrucción o híbrida

Cuándo Pedir Ayuda Urgente

La recuperación urgente tiene sentido cuando backup, crash recovery, flashback o reparación de storage no bastan para volver al servicio sin pérdida de datos inaceptable.

  • La base de datos no abre o no monta El startup falla por daño de medios, restore incompleto, archivos faltantes o metadatos corruptos.
  • Datos importantes fueron borrados, truncados o eliminados La recuperación a nivel de objeto puede ser posible aunque no exista flashback ni backup lógico.
  • Los backups faltan, son inconsistentes o no sirven Analizamos conjuntos parciales de RMAN, dump, filesystem, cinta, snapshot y copias de datafiles.
  • Hubo daño de storage, filesystem o ransomware El trabajo se centra en bloques legibles, metadatos supervivientes y targets de exportación validados.

Objetivos de Recuperación

El objetivo inmediato no es forzar la apertura de la base dañada a cualquier precio. El objetivo práctico es identificar los datos recuperables, elegir la vía de menor riesgo y entregar filas, tablas o archivos validados para cargar en un entorno limpio.

  • Preservar evidencia primero Trabajar desde copias siempre que sea posible y evitar reparaciones destructivas sobre originales.
  • Recuperar lo que importa Priorizar schemas, tablas, rangos de tiempo y muestras de validación críticas para el negocio.
  • Separar software y servicios Las herramientas DBRECOVER son productos self-service. La consultoría urgente se cotiza por separado.

Escenarios Urgentes que Podemos Evaluar

El alcance original del servicio cubre borrado lógico, fallo de storage, backups rotos, daño del diccionario Oracle, problemas de metadatos ASM y datafiles huérfanos. En la práctica, cada caso empieza con una evaluación de recuperabilidad porque el flujo más seguro depende de qué archivos siguen legibles y qué operaciones se intentaron después del incidente.

01
Tablas eliminadas, recreadas o truncadas

Evaluar si segmentos antiguos, metadatos del diccionario o bloques restantes aún sirven para recuperación por tabla.

02
Tablespace eliminado

Comprobar si datafiles, extents ASM, copias de filesystem o snapshots conservan datos de objetos utilizables.

03
Export, Data Pump o RMAN inutilizable

Evaluar dumps parciales, backup sets inconsistentes, piezas dañadas y rutas alternativas de extracción por archivo.

04
Filas eliminadas

Analizar si los datos eliminados permanecen en bloques, undo, redo, archived logs o datafiles copiados.

05
ASM disk group no monta

Revisar headers de disco, metadatos de asignación, extents legibles y posibles rutas directas de recuperación de datafiles.

06
Filesystem o storage corrupto

Trabajar desde medios clonados y concentrarse en bloques de base de datos legibles en vez de reparar el original.

07
SYSTEM datafile eliminado

Si falta el diccionario, la recuperabilidad depende de archivos supervivientes, estructura de objetos y escaneo heurístico.

08
Usuario o schema eliminado

La evaluación se hace a nivel de objeto y datafile, sobre todo si los segmentos del usuario siguen parcialmente legibles.

09
Incidentes ORA-00600 u ORA-07445

Los errores internos se agrupan por subsistema afectado: block cache, filas, undo, redo, diccionario o control file.

10
La base de datos no abre

Elegir entre restore, completar recovery, extracción offline o reconstrucción en una base limpia.

11
Bloques corruptos

Inspeccionar file number, block number, segmento propietario, tipo de objeto afectado y copias alternativas.

12
Header o metadatos ASM corruptos

Evaluar daño de metadatos del disk group, consistencia de discos miembros y posible reconstrucción de extents.

13
Restore inconsistente o archived logs faltantes

Cuando recovery normal no avanza, extraer tablas puede ser más seguro que forzar una apertura no soportada.

14
Backup mezclado por rotación de cinta

Identificar qué archivos pertenecen juntos, qué rangos SCN sirven y qué datos aún pueden exportarse.

15
Corrupción del diccionario o bootstrap

Comprobar si los metadatos del sistema bastan para parseo normal o si se requiere escaneo sin diccionario.

16
Pérdida del SYSTEM tablespace

Si el diccionario se perdió, el escaneo heurístico a veces puede inferir tablas, columnas y tipos desde bloques de datos.

17
Datafiles huérfanos

Incluso un solo datafile superviviente puede contener datos de tablas recuperables si la estructura de bloques sigue legible.

18
Columnas eliminadas

La recuperación por columna depende de la versión, cambios de estructura, reutilización de bloques y redo o backups disponibles.

Importante: la recuperabilidad no se asume solo por el código de error. La primera tarea es preservar los archivos restantes y establecer si los datos objetivo aún existen en datafiles, undo, redo, archived logs, backups, snapshots o bloques supervivientes del storage.

Incidentes Oracle que Analizamos

En Oracle, el trabajo urgente suele empezar con un open fallido, mount fallido, datafile ilegible, problema ASM o restore inconsistente. DBRECOVER ayuda a inspeccionar y extraer datos desde archivos dañados aunque la instancia original no pueda completar la recuperación normal.

  • Corrupción de bloque, fila, índice, diccionario y UNDO Incluye consultas que fallan, validaciones con errores de referencia cruzada o recuperación bloqueada.
  • Fallos de ASM disk group y filesystem Evaluamos extents legibles, headers de disco dañados, problemas de metadatos y datafiles huérfanos.
  • Recuperación sin backup o con backup parcial Incluye archived logs faltantes, rotación de cinta incorrecta, SYSTEM datafile eliminado y datafiles de usuario huérfanos.
Familias comunes de errores Oracle
ORA-00600 / ORA-07445 Errores internos y caídas de proceso ORA-01578 / ORA-26040 Bloque corrupto o acceso a bloque NOLOGGING ORA-08103 / ORA-01410 Inconsistencias de objeto o ROWID ORA-01498 / ORA-01499 Fallos de validación tabla/índice ORA-01113 / ORA-01115 Datafile requiere recovery o error de lectura ORA-01122 / ORA-01157 Fallo de verificación o identificación de datafile ORA-01194 / redo faltante Recovery incompleto o archivos inconsistentes ORA-15032 / ORA-15196 Problemas de mount y metadatos ASM

Referencia de Errores Oracle para Triaje

Estas familias de errores son señales útiles durante el triaje. No prueban por sí solas que los datos sean recuperables o irrecuperables, pero ayudan a ubicar si la falla probable está en bloques, índices, undo, redo, diccionario, control files o ASM.

Familia de error Área probable Foco de recuperación
ORA-01578, ORA-26040 Bloque de datos corrupto o bloque cargado con NOLOGGING / operación unrecoverable. Mapear archivo y bloque al segmento, revisar copias alternativas y aislar filas u objetos afectados.
ORA-08103, ORA-01410 Inconsistencia de identidad de objeto o ROWID, a menudo por diccionario, segmento o bloque. Comparar metadatos con bloques y decidir si la extracción por tabla es más segura.
ORA-01498, ORA-01499, ORA-08102 Inconsistencia tabla/índice o clave de índice no coincidente. Determinar si la tabla es legible, reconstruir índices o exportar datos sin depender de índices dañados.
ORA-00600 [12700], [kdsgrp1] Una entrada de índice apunta a una fila ausente o inconsistente, o hay anomalía de lectura consistente. Validar si la corrupción está en bloques de datos, índices, undo o estado de consistencia de lectura.
ORA-00600 [3020] Recovery bloqueado por diferencia entre registros redo y bloques de base de datos. Revisar disponibilidad de redo, SCN de archivos, consistencia de backups y extracción por objeto.
ORA-00600 [4193], [4194], [4137] Diferencia de secuencia, registro o transacción entre undo y redo. Preservar undo y redo, evitar intentos repetidos de open y evaluar extracción desde copias estables.
ORA-00600 [2662], señales de lost write Diferencia de SCN o block SCN adelantado respecto al estado actual. Evaluar linaje de archivos, orden de restore, escrituras perdidas y posibilidad de export limpio.
ORA-00600 [25012], [25026], [25027] Inconsistencia de relative file number, absolute file number, RDBA o metadata de tablespace. Reconstruir el mapeo de archivos y decidir qué tablespaces y datafiles pueden parsearse.
ORA-15032, ORA-15040, ORA-15042, ORA-15196 Problema de mount, metadatos, disk header o validación de header en ASM. Proteger discos ASM, inspeccionar metadatos e intentar recuperación por datafile o extent desde copias.
ORA-00333, ORA-00704 Error de lectura de redo log o fallo del proceso bootstrap. Revisar copias de redo, archived logs, metadatos de sistema y si se requiere reconstrucción desde datos extraídos.

Para errores internos severos, incluya el primer error, call stack si existe, extracto del alert log, encabezado del trace file, versión de base de datos, plataforma y lista de datafiles y piezas de backup.

Casos Urgentes MySQL e InnoDB

En MySQL, muchos incidentes requieren recuperación a nivel de archivo cuando el servidor no inicia o cuando DROP, TRUNCATE, daño de filesystem o ransomware deja solo archivos InnoDB parciales. DBRECOVER for MySQL inspecciona archivos localmente e identifica filas recuperables.

  • Corrupción de página y tablespace InnoDB Recuperación desde .ibd dañados, problemas de ibdata1 y fallos de lectura por página.
  • Base de datos eliminada o archivos de schema faltantes Usamos artefactos restantes, páginas de diccionario o definiciones de tablas para reconstruir exports.
  • Ransomware y cifrado parcial Validamos qué páginas, tablas y filas siguen legibles antes de planear la reconstrucción.
Señales de triaje MySQL
InnoDB: Database page corruption on disk InnoDB: Page may be an index page where index id is unknown InnoDB: Log sequence number is in the future InnoDB: Trying to access page number outside the tablespace mysql> DROP DATABASE production; Snapshot de filesystem con archivos .ibd parciales

Proceso de Servicio Urgente

Una recuperación apresurada puede empeorar el daño. El proceso mantiene intacta la evidencia original mientras demuestra rápido si conviene extracción por tabla, reparación de restore o reconstrucción híbrida.

1. Triaje

Revisión de síntomas, versiones, plataforma, storage, backups, alert logs y prioridades de negocio.

  • EntradaErrores y lista de archivos
  • SalidaPlan por riesgo y prioridad

2. Preservación

Trabajar desde copias cuando sea posible y evitar comandos que sobrescriban evidencia recuperable.

  • EntradaDatafiles y logs
  • SalidaConjunto de trabajo seguro

3. Validación

Confirmar schemas, conteos de filas, muestras y formato de exportación antes de la entrega final.

  • EntradaLista de tablas críticas
  • SalidaSQL o CSV listo para cargar
Oracle

Recovery Incompleto

Archived logs faltantes impiden abrir la base. La vía de recuperación se centra en extraer tablas críticas desde datafiles legibles.

Objetivo: exportar filas validadas a una base limpia.

Oracle ASM

Daño de Disk Group

Los metadatos ASM impiden el mount normal. El triaje determina si archivos o extents pueden leerse y si la extracción por tabla es viable.

Objetivo: preservar extents legibles y recuperar objetos prioritarios.

MySQL

Daño en Archivos InnoDB

El servidor falla en crash recovery. DBRECOVER escanea .ibd directamente para validar schema, lectura de páginas y alcance de exportación.

Objetivo: crear salida MySQL dump recargable.

Qué Enviar en el Primer Email

Un primer mensaje útil reduce el tiempo de triaje. No suba datos de producción hasta acordar un método seguro de transferencia. Empiece con metadatos, logs y una lista clara de tablas críticas.

  • Detalles de la base Versión Oracle o MySQL, sistema operativo, tipo de storage, charset, block size y cambios recientes.
  • Línea de tiempo del fallo Qué ocurrió primero, qué comandos se probaron y si los archivos se modificaron después.
  • Objetivo de recuperación Schemas, tablas, conteos aproximados, ventana temporal y límite aceptable de pérdida.
Plantilla de email
Asunto: Solicitud Urgente de Recuperación de Base de Datos Base: Oracle 19c / MySQL 8.0 Plataforma: Linux / Windows, filesystem o ASM / InnoDB Fallo: errores exactos y hora del primer fallo Archivos: datafiles, control files, redo, archives, .ibd, backups Acciones probadas: restore, recover, startup, repair, fsck, storage tools Datos prioritarios: schemas, tablas, rango de fechas, muestras de validación

¿Necesita Recuperación Urgente?

Envíe el primer error, versión de base de datos, lista de archivos y objetivo de recuperación. El soporte de pago se cotiza por separado de las licencias de DBRECOVER.

Contactar Soporte Urgente Leer guía sin backup