respaldo - Oracle rellena la tabla de copia de seguridad de la tabla principal

restaurar backup oracle

Question

El programa al que estoy asignado actualmente tiene el requisito de copiar el contenido de una tabla en una tabla de respaldo, antes del procesamiento real.

Durante la revisión del código, un compañero de trabajo señaló que

INSERT INTO BACKUP_TABLE
SELECT *
FROM PRIMARY_TABLE

es indebidamente arriesgado, ya que es posible que las tablas tengan columnas diferentes y diferentes órdenes de columnas.

También estoy bajo la restricción de no crear / eliminar / renombrar tablas. ~ Suspiro ~

Se espera que las columnas de la tabla cambien, por lo que simplemente codificar los nombres de las columnas no es realmente la solución que estoy buscando.

Estoy buscando ideas sobre una forma razonable y no arriesgada de hacer este trabajo.

Answer 1

¿Con qué frecuencia cambias la estructura de tus tablas? Su método debería funcionar bien siempre que la estructura no cambie. Personalmente, creo que sus DBA deberían darle un mecanismo para descartar la tabla de respaldo y volver a crearla, como un procedimiento almacenado. Tuvimos algo similar en mi último trabajo para truncar ciertas tablas, ya que truncar es con frecuencia mucho más rápido que DELETE FROM TABLE; .

Answer 2

¿Hay alguna razón por la que no puedas simplemente enumerar las columnas en las tablas? Asi que

INSERT INTO backup_table( col1, col2, col3, ... colN )
SELECT col1, col2, col3, ..., colN
FROM primary_table

Por supuesto, esto requiere que vuelva a visitar el código cuando cambie la definición de una de las tablas para determinar si necesita hacer cambios en el código, pero generalmente es un pequeño precio a pagar para aislarse de las diferencias en el orden de las columnas, diferencias en la columna nombres y diferencias irrelevantes en las definiciones de tabla.

Answer 3

¿La tabla de respaldo permanece? ¿Mantiene los datos permanentemente, o es solo una copia de los valores actuales?

Lástima que no se pueda crear / eliminar / renombrar / copiar. De lo contrario, si es a corto plazo, solo se usa en caso de que algo salga mal, entonces puedes soltarlo al comienzo del proceso y hacer algo como

create table backup_table as select * from primary_table;

Su mejor opción puede ser hacer que la selección sea explícita, como

insert into backup_table (<list of columns>) select <list of columns> from primary_table;

Podrías generar eso construyendo una cadena SQL del diccionario de datos, y luego ejecutando inmediatamente. Pero aún estará en riesgo si la tabla de respaldo no contiene todas las columnas importantes de la tabla primaria.

Tal vez solo quiera hacerlo explícito, y generar un error importante si la tabla de respaldo no existe, o si alguna de las columnas de la tabla primaria no está en la tabla de respaldo.

Answer 4

Podrías probar algo como:

CREATE TABLE secondary_table AS SELECT * FROM primary_table;

No estoy seguro de si eso copia automáticamente los datos. Si no:

CREATE TABLE secondary_table AS SELECT * FROM primary_table LIMIT 1;
INSERT INTO secondary_table SELECT * FROM primary_table;

Editar:

Lo siento, no leí tu publicación por completo: especialmente la parte de restricciones. Me temo que no sé cómo. Me imagino que usaría un procedimiento que primero describe ambas tablas y las compara, antes de crear una consulta larga de inserción / selección.

Aún así, si está usando una tabla de respaldo, creo que es muy importante que coincida exactamente con la original.

Answer 5

Si tuviera esta situación, recuperaría las definiciones de columna para las dos tablas justo al comienzo del problema. Entonces, si fueran idénticos, procedería con lo simple:

INSERT INTO BACKUP_TABLE
SELECT *
FROM PRIMARY_TABLE

Si fueran diferentes, solo procedería si no hubiera columnas críticas que faltan en la tabla de respaldo. En este caso, usaría este formulario para la copia de respaldo:

INSERT INTO BACKUP_TABLE (<list of columns>)
SELECT <list of columns>
FROM PRIMARY_TABLE

Pero también me preocuparía qué pasaría si simplemente detuviera el programa con un error, por lo que incluso podría tener un plan de respaldo donde usaría el segundo formulario para las columnas que están en ambas tablas, y también volcar un archivo de texto con el PK y las columnas que faltan en la copia de seguridad. También registre un error aunque parezca que el programa se completó normalmente. De esa forma, podrías recuperar los datos si sucediera lo peor.

Realmente, este es un síntoma de los malos procesos en algún lugar que deberían abordarse, pero la programación defensiva puede ayudar a convertirlo en un problema ajeno, no tuyo. Si no notan el mensaje de error de registro que les dice sobre el volcado de texto con las columnas que faltan, entonces no es su culpa.

Pero, si no codifica a la defensiva, y sucede lo peor, será en parte culpa suya.