Registros corrupto en tabla sga_detalle_examen

Buenas noches.
Como les va?
Tengo un inconveniente que se genera por problemas en los índices de una tabla, el problema fue que varios de los índices se dañaron, con lo cual se corrieron dos script que buscan reestablecer los índices de las tablas que usa SIU, los script son “updstssql.sql” y “updstssql_high_tablas.sql” provistos en algún momento por ustedes.
Luego se corrieron el proceso de liberación de log “ontape -a” para libración de logs.
Luego de todo esto la base de datos volvió a su funcionamiento normal. Pero cuando se fue a cerrar un acta de examen final de un alumno, nos arroja un error al momento de querer abrir la misma para su cierre, error que se ve en la imagen que se adjunta.
Buscando cual es el motivo del error note que dentro de la tabla “sga_detalle_acta” existen menos alumnos que los que realmente figuran en el acta que se imprimió, verifique con la tabla de log_detalle_acta y noto que en esa tabla figuran todos los alumnos que realmente existen en el acta impresa.
Se me ocurrió solucionar dicho inconveniente haciendo directamente un insert con todos los datos faltantes que los saco de la tabla log pero al ejecutar dicha consulta me da un error de registro duplicado, es decir, evidentemente los índices de dicha tabla luego de haber corrido los anteriores script no se arreglaron, los volví a correr y sigue igual. Desactive los triggers y volví a intentar el insert y da el mismo mensaje, registro duplicado, pero en realidad no existe en la tabla.
Con lo cual me llevo a seguir buscando en el foro algo que me oriente a una solución posible a este problema, llegue a este hilo “https://foro.comunidad.siu.edu.ar/index.php?action=profile;area=showposts;u=599”, el cual plantea la regeneración de los índices de la tabla “sga_detalle_acta” con la previa eliminación de los mismos.
Mi duda radica en que recomendaciones me darían antes de correr esos comando que se proponen en ese hilo? hacer un backup de la tabla y recién correr porque tengo miedo que si hago eso y llega a haber un problema en el medio la tabla estimo quedara totalmente corrupta sin poder accederla de nuevo.
Corrí además el comando “oncheck -ciI SIU_295” sobre la base de datos y surgieron errores de índices y advertencias en múltiples tablas de la base de datos. Con lo cual deduzco que el problema esta sobre los índices de las tablas. Al correr el comando sobre consola arroja los errores que va detectando pero a medida que avanza el proceso la información que se arrojo anteriormente se pierde, existe forma alguna de mandar la respuesta a un archivo o que no se pierda la información que se informa desde un principio, porque por más que retroceda con el scroll solo recupero las ultimas dos paginas que me va informando el comando sobre la consola. Y como si fuera poco a esto se le suma que el Informix comenzó a funcionar lento, demora mucho en responder a pedidos que le realicen desde el Gestión como por el 3W.
Tengo entendido que corriendo los comando “oncheck -cd -y” para reparar las incoherencias de cada página asi como el comando “oncheck -ci -y” para reparar índices de las tablas pero recomiendan hacer esta parte con “SQL DROP INDEX y CREATE INDEX” ya que el comando oncheck demora mucho en su ejecución.
Es por eso que mi consulta esta en cual comando correr o recomiendan correr o si existe otra solución al problema que se me presenta actualmente sin necesidad de eliminar los índices?
La regeneración de los índices solo afectaría a la tabla sga_detalle_acta o también tendría que tener en cuenta otra/s tabla/s?
Saludos y gracias!!!

Hola. Buenos días.
Les comento lo que pude avanzar en este tema de la tabla con problemas de índices.
Realice la corrida de los siguientes comandos oncheck -cd SIU -y oncheck -cD SIU -y para reparar las incoherencias.
Luego hice correr este otro comando “oncheck -ci SIU -y” para verificar y reparar el orden de los valores clave y la consistencia de los enlaces de nodos horizontales y verticales para todos los índices asociados con la tabla especificada.
Por último corrí los script que buscan reestablecer los índices de las tablas que son “updstssql.sql” y “updstssql_high_tablas.sql” provistos en algún momento por ustedes.
Y por último hice la limpieza de log con el comando ontape -a sobre la base de datos.
Luego de hacer todo esto el error no se soluciono, sigue el problema con el tema índice sobre la tabos archivos que se informan para la carga del Araucano Nominal por ejemplo, para cuando se desea reimprimir actas de exámenes ya generadas con notas. Para cuando se desea rectificar un acta o anular.
No corrí el proceso de eliminación y generación de los índices porque quiero saber que opinan sobre dicho situación y que me aconsejan.
Estamos trabajando con el informix 2.9.1 y la versión 2.9.5 del SIU Guaraní.
Estoy analizando la posibilidad de exportar todo los datos a una nueva estructura de base de datos generándola desde cero a la misma, pero quisiera saber que comando recomiendan ejecutar solamente para traer los datos, yo venía trabajando con “dbexport” y “dbimport” pero cada vez que los ejecuta siempre tengo problemas con los sp, siempre me arroban problemas y abortan la ejecución del exportar y los debo de volver a regenerar y así estoy hasta que lo puedo lograra generar a los archivos pero en este caso yo solo necesito los datos y luego debería de hacer la salvedad del tema de los índices.

Hola Victor como andas ?

Primer algunas cosas generales

1- El DROP INDEX no borra datos, solo los indices, los cuales se pueden volver a crear con un create index, por lo tanto no hay riesgo en dropear los indices, en tanto y cuanto tengas un script para re-crearlos posteriormente.

2- el oncheck para reparar, NO siempre repara, intenta reparar, pero muchas veces no lo logra, asi que no le pondria muchas fichas a esa opcion

3- el dbexport y dbimport son la forma de generar una nueva copia de la base. Lo de los procedures, qe dan error y tener que arreglar, es verdad que es un garron, pero hay que arreglarlos y tratar de no perder ese arreglo para futuros bdexport/dbimports.

Dicho esto, yo te recomiendo que hagas una copia de la tabla nueva con otro nombre, asegurate que tenga todos los registros que tenia la tabla original, que tenga los mismo indices, y tambien tenga la misma integridad referencial. inclusive vas a tener que acomodar las foreing keys que actualmente apuntan a tu tabla actual para que en el futuro apunten a la nueva tabla.

Por ultimo hace un renombre de las tablas, como si hicieras un enroque y te quedara una tabla nueva, con indices nuevos y toda la data.
Esta tarea que yo te describo requiere varios scripts y es un poco compleja, te sugiero que lo hables con la gente de Guarani, ellos la tienen re- clara

Por ultimo y para mas adelante, porque no se pasan al Guarani 3 ? La base de datos informix es anterior al 2000, que ya tiene mas de 20 años que cada vez tiene menos soporte y cada vez va a traer mas problemas, creo que vale la pena hacer el esfuerzo y migrar

saludos
Ignacio

Hola Ignacio.
Como te va?
Desde ya te doy las gracias por tu tiempo y haberte tomado el tiempo en leer mi consulta.
Te comento que siempre utilice el dbexport y dbimport pero con esto de los sp que dan error llegue a pensar que había otra alternativa para poder generar un backup de la base de datos. Pero en fin, me pondré en campaña de comenzar a migrar, por otro lado quería hacerte una consulta, cuando lanzo el dbexport desde consola del informix, a medida que avanza el proceso y van saltando los error de los sp, el proceso se aborta y comienza el proceso de corregir el sp, pero en ocasiones la información que se observa sobre consola del informix cuando se aborta, al volver sobre el historial note que tiene limitaciones, solo muestra a lo sumo las última 30 líneas más o menos de lo que se estuvo exportando y en ocasiones dificulta el poder saber el nombre del sp que dio el error ya que no sale entre las líneas que deja ver la consola.
Existe alguna manera de poder mandar la salida de lo que va mostrando la consola sobre algún archivo o para poder ver luego donde quedo, abrir el script que el comando genera, note que solo figura los proceso que van generándose de manera correcta. Capaz que existe y desconozco de algún comando que ayuda a seguir el proceso de generación del script desde otra consola e ir viendo que va avanzando y que falta procesar durante la exportación de la base?
Por otro lado existe alguna forma de saber que otras tablas fueron afectadas con este tipo de problema de índices o irán saliendo a medida que vayan utilizando al Gestión y al 3w?
Con respecto al tema SIU 3, si queremos migrar a esa versión desde el año pasado pero no podemos conseguir el instalador del mismo, sabes de donde se lo puede bajar así podemos hacer una instalación local aunque sea?
Saludos y desde ya te doy las gracias por todo.

                                                                                                                                              Cesar

Hola Victor

Para:
Existe alguna manera de poder mandar la salida de lo que va mostrando la consola sobre algún archivo o para poder ver luego donde quedo, abrir el script que el comando genera

Si estas en linux, podes probar algo tipo:
dbexport base >>archivo_errores.txt 2>>archivo_errores.txt
eso va a mandar toda la salida del dbexport a un archivo llamado archivo_errores.txt, si queres al mismo tiempo en otra consola podes hacer un:
tail -f archivo_errores.txt
y el tail te va a ir mostrando el contenido del archivo_errores.txt a medida que se va generando.
Ojo que al hacer el dbexport y el tail en ambas consolas tenes que pararte en el mismo directorio

eso del >> y el 2>> es gracias a las capacidades de redireccionamiento del shell y algunas cosas copadas que tiene el linux. En linux, cuando un proceso escribe en la pantalla lo hace a traves del standard output o a traves del standard error, no hay otra forma. Cuando vos ves el mensaje en la consola, no sabes por donde llego a la consola (si fue por stdout o fue por stderr). Pero el shell te permite re-direccionar ambos a un archivo. el stdout con un > o un >> y el stderr con 2> o 2>>

Hola Ignacio.
Como te va?
Muchas gracias por responder y solucione el problema de saber que sp se daño.

                                                                                                                                                        Cesar

Hola Cesar,

Pueden existir procecimientos con el mismo nombre, incluso con la misma cantidad de parametros, pero deben ser de distinto tipo de datos.
Te podes fijar los tipos de datos y ver si hay diferencias por ahi ?

En ese caso, para borrar tenes que hacer algo tipo

DROP PROCEDURE compare(int, int);

es decir especificar nombre del procedure y entre parentesis los tipos de datos que recibe

Si tenes duplicados los procedures y ambos tienen la misma cantidad de parametros y son del mismo tipo de datos, entonces hay algo mal en la base.

En ese caso te sugiero exportar la base, borrar el procedure duplicado en el archivo SQL que genera el dbexport y luego volver a importarla

saludos
Ignacio

Hola Ignacio.
Cómo te va?
Te comento que lo resolví renombrando el sp dentro de la tabla sysprocedure. Lo ubique por su ID y cambie el nombre de uno de los dos sp duplicados, esto luego me permitió luego dropear el que estaba renombrado y con ello se solucionó las sp duplicados.
Ahora estoy con otra situación, luego de pasar varios días dropeando y volviendo a generar cada uno de los sp que el dbexport abortaba su proceso de exportación llegué a otra situación que no sé cuál es el motivo que genera este problema.
El problema está en qué ahora mando a ejecutar el dbexport y lo único que hace ahora es registra los usuarios del sistema y aborta el proceso de exportación, antes por lo menos procesaba y se iba generando con todos los sp hasta que daba con uno corrupto y abortaba pero podía está procesando un buen rato y se lograba ver en consola lo que iba haciendo ahora directamente mando a ejecutar el dbexport y así como entra en ejecución se aborta dando un mensaje de exportación errónea. Pensé que era el último sp que dropp y volví a generar ya que con ese sp inicia el archivo del dbexport así que lo volví a regenerar y sigue igual.
El archivo que se genera la poca información que muestra no ayuda en nada. Reinicie el Informix con oninit -v e hice unas consultas desde el Siu gestión y responde, lento pero responde. No sé por dónde encarar este inconveniente así pueda hacer que el dbexport pueda continuar con tu tarea. Algún comando o archivo al que se pueda ver y saber o tener algún tipo de referencia del motivo de este problema del porque el dbexport aborta el proceso!? Desde ya doy las gracias. Cesar

Sumo una imagen del error que me da el dbexport al correrlo.


dbexport_error.PNG

dbexport_error.PNG_thumb.png

Hola Victor

Huuu, que tema ese error. No sera que esta relacionado con los cambios que hiciste en el catalogo ? Hacer UPDATEs en el catalogo es bastante riesgoso, a veces te sale bien, pero te puede quedar mal y despues da errores de todo tipo.

Es posible que vuelvas para atras el cambio que hiciste al nombre del procedure ? y luego pruebes el dbexport a ver si da el error ?

Probaste hacer un dbschema ? a ver si da error , si el problema esta en el catalogo el dbschema deberia dar el mismo error

saludos
Ignacio

Hola Ignacio.
Como te va?
Gracias por responder.
El tema de schema nunca lo utilice, como sería la sentencia y que parámetros debería de utilizar?
Te comento, estoy pensando hacer lo siguiente, se realiza una imagen backup de la maquina servidor regularmente, creo que 2 o 3 veces durante el día, mi idea sería levantar en otra pc una imagen de dicho servidor, conectarme a ese informix y borrar todos los sp de esa base de datos pertenecientes al dba y correr nuevamente el dbexport y ver si con eso logro obtener los datos de las correspondientes tablas, pienso que esa sería otra alternativa a este problema. La otra es desde el Razor intentar de hacer un backup de la base pero no se si es una herramienta muy fiable para este tipo de cosas.
Saludos y gracias!!!

Hola Victor

dbschema -d basededatos archivo.sql

en archivo.sql te deja todo el DDL de la base de datos (DDL sentencias SQL para crear las tablas, indices, triggers, procedures,etc, todo excepto datos)

No estoy seguro si va el -d y si necesita un > antes de archivo.sql. Vos proba las variantes te va a salir

saludos

Hola.
Gracias por responder.
Te comento que hice la consulta y me de error, verifique el motivo del error y me di cuenta que el informix directamente se cae, lo reinicie y al momento de conectarse desde el siu se cae.
Esto ya sucedió otras veces y lo solucionaba de la siguiente manera, estado con el usuario informix, mandaba a ejecutar el comando oninit -v, pero ahora al hacer eso directamente termina abortando el proceso y nunca llega a la línea “VERBOSE OUTPUT COMPLETE: MODE = 5”, ya que por lo general llegaba hasta ese punto y luego desde otra ventana del informix mandaba a ejecutar los comando onstat -l para ver situación de log y liberarlos se era necesario. Y por último me conectaba a la base de datos desde el sqleditor y ejecutaba las consultas de reparación de índices, pero todo esto, lo hacia siempre que el comando oninit -v llegase a dicha línea pero ahora directamente no puedo hacer ni siquiera la ejecución del onstart -l, que me da problemas de informix caído, ejecute el siguiente comando “Oninit –iyv” el cual inicia toda una nueva instancia del informix con sus correspondientes recursos pero al ejecutar dicho comando per el mismo me termina devolviendo un error indicando faltante de espacio en el root dbspaces. Adjunto imágenes de lo que devuelve al ejecutar el “oninit -v” y lo que devuelve el “oninit -iyv” con el error de espacio. Trate de ejecutar el comando “onstat -d” como para obtener un informe sobre el uso de los recursos del informix pero da error en la ejecución del mismo.
Este proceso es el que se indica para el aumento de espacios en el root dbspace.
1- Creo el archivo fisico del chunk.
copy nul rootdbs_data.002 (Segundo imagen sería el rootdbs_data.002)
onspaces -c -d temporary -t -p E:\IFMXDATA\ol_guarani\rootdbs_data.002 -o 0 -s 2.000.000
ontape -s -L 0
Pero al hacer eso me devuelve error de “shared memory not initialized for INFORMIXSERVER ol_guarani”. error que lo solucionaba corriendo como te comente anteriormente el comando “oninit -v”.
Espero me orientes un poco sobre esta situación como para poder continuar a ver si logro sacar un backup de mi base de datos.
Saludos Cesar


oninit-v.PNG

oninit-v.PNG_thumb.png

oninit-iyv.PNG

oninit-iyv.PNG_thumb.png

physical-log-rootdbs.PNG

physical-log-rootdbs.PNG_thumb.png

hola Victor como va

En primer lugar, no llego a entender bien la relacion de esta pregunta con el tema que tratabamos en el anterior post.
No me queda claro en que punto se hizo necesario hacer el “oninit -ivy”, ya que no es usual tener que hacerlo porque formatea todo el Informix

De todas maneras, en este post, lo que falla el “oninit -ivy”. Aclaro q este comando se deberia correr UNA sola vez en la vida de una instancia Informix, ya que destrutye todo el informix y lo reinicia por completo. Seria algo asi como un FORMATEO del disco C: en windows.

Por lo que veo , el tamano del ROOT DBSPACE definido por el parametro ROOTSIZE en el archivo de configuracion es muy bajo para todo lo que tiene que meter Informix en el ROOT DBSPACE al momento de inicializar. Asi que yo sugiero que edites el archivo de configuracion e incrementes de 50000 a 60000 el ROOTSIZE , grabalo y volve a intentar el onitni -vyi.

saludos
Ignacio

Hola Ignacio.
Si tienes razón, una cosa no tiene nada que ver con lo que comenzó siendo este hilo. Inicio como un pedido de ayuda para exportar datos de la base y termino preguntándote por cuestiones del funcionamiento de los rootdbs space.
Pero todo esto que te voy consultando va saliendo a medida que trato de obtener un backup sobre la base datos en producción y a medida que voy tratando de ver como puedo hacer para lograr obtener un backup de la base sobre producción se esta dando este problema. La base de estar lenta ahora directamente ni responde. El informix se cuelga, con lo cual intuí que era algún tema de espacio, la corrida del comando “onstat -d” que daría un panorama frente a este tema pero al no poder correr ese comando como ningún otro comando, no me quedo otra que recurrir al “oninit -ivy” pero tampoco dio resultado alguno, finalmente se decidió ir a un backup del día Sábado con lo cual volvimos a tenerlo al SIU en linea, con lo cual pude ejecutar el comando “oninit v” y luego pude ejecutar el comando "onstat -d " obteniendo el siguiente informe.

C:\Program Files\informix>onstat -d

Informix Dynamic Server 2000 Version 9.21.TC4 – On-Line – Up 00:26:16 – 8
30272 Kbytes

Dbspaces
address number flags fchunk nchunks flags owner name
ebe37d0 1 0x1 1 2 N informix rootdbs
ec229b0 2 0x2001 2 1 N T informix temporary
ec22af8 3 0x1 3 1 N informix logical_logs
ec22c40 4 0x1 4 1 N informix physical_logs
ec22d88 5 0x1 5 1 N informix datos
5 active, 2047 maximum

Chunks
address chk/dbs offset size free bpages flags pathname
ebe3918 1 1 0 500000 124758 PO- C:\IFMXDATA\ol_guarani\rootdbs_dat.000
ec222a8 2 2 0 500000 499947 PO- c:\IFMXDATA\ol_guarani\temporary.000
ec22410 3 3 0 511750 261697 PO- c:\IFMXDATA\ol_guarani\logical_logs.000
ec22578 4 4 0 200000 12447 PO- c:\IFMXDATA\ol_guarani\physical_logs.000
ec226e0 5 5 0 500000 496797 PO- c:\IFMXDATA\ol_guarani\datos.000
ec22848 6 1 0 500000 493017 PO- C:\IFMXDATA\ol_guarani\rootdbs_dat.001
6 active, 2047 maximum

Y al correr el comando “onstat -l” obtengo este informe

C:\IFMXDATA\ol_guarani>onstat -l

Informix Dynamic Server 2000 Version 9.21.TC4 – On-Line – Up 01:12:19 – 8
30272 Kbytes

Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 0 8 3 1 3.00
phybegin physize phypos phyused %used
400035 187500 123135 0 0.00

Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-3 0 8 32 6 5 5.3 1.2
Subsystem numrecs Log Space used
OLDRSAM 32 4964

address number flags uniqid begin size used %used
c22689c 1 U-B---- 1002 32abcd 25000 2 0.01
c2268b8 2 U-B---- 1003 300035 25000 2 0.01
c2268d4 3 U—C-L 1004 3061dd 25000 118 0.47
c2268f0 4 U-B---- 992 30c385 25000 2 0.01
c22690c 5 U-B---- 993 11899b 25000 2 0.01
c226928 6 U-B---- 994 11eb43 25000 2 0.01
c226944 7 U-B---- 995 124ceb 25000 2 0.01
c226960 8 U-B---- 996 31252d 25000 2 0.01
c22697c 9 U-B---- 997 330d75 25000 2 0.01
c226998 10 U-B---- 998 336f1d 25000 2 0.01
c2269b4 11 U-B---- 999 3186d5 25000 3 0.01
c2269d0 12 U-B---- 1000 31e87d 25000 2 0.01
c2269ec 13 U-B---- 1001 324a25 25000 2 0.01

Noto que todos los parámetros están ok o me equivoco?
Con lo cual vuelvo a caer nuevamente en la situación que la base de datos esta funcionando o me equivoco, o tengo que ver algo más que estoy dejando de lado y que esta generando esta situación del que el informix de cuelga y no levanta más?
Saludos

                                                                                                                        Cesar

Hola Cesar, como va

basado en esta salida
Informix Dynamic Server 2000 Version 9.21.TC4 – On-Line – Up 00:26:16 – 8
30272 Kbytes

Dbspaces
address number flags fchunk nchunks flags owner name
ebe37d0 1 0x1 1 2 N informix rootdbs
ec229b0 2 0x2001 2 1 N T informix temporary
ec22af8 3 0x1 3 1 N informix logical_logs
ec22c40 4 0x1 4 1 N informix physical_logs
ec22d88 5 0x1 5 1 N informix datos
5 active, 2047 maximum

Chunks
address chk/dbs offset size free bpages flags pathname
ebe3918 1 1 0 500000 124758 PO- C:\IFMXDATA\ol_guarani\rootdbs_dat.000
ec222a8 2 2 0 500000 499947 PO- c:\IFMXDATA\ol_guarani\temporary.000
ec22410 3 3 0 511750 261697 PO- c:\IFMXDATA\ol_guarani\logical_logs.000
ec22578 4 4 0 200000 12447 PO- c:\IFMXDATA\ol_guarani\physical_logs.000
ec226e0 5 5 0 500000 496797 PO- c:\IFMXDATA\ol_guarani\datos.000
ec22848 6 1 0 500000 493017 PO- C:\IFMXDATA\ol_guarani\rootdbs_dat.001
6 active, 2047 maximum

Esto: – On-Line – Up 00:26:16
Indica que el Informix esta levantado y funcionando hace 26 minutos

Esto: ec226e0 5 5 0 500000 496797 PO- c:\IFMXDATA\ol_guarani\datos.000
Indica que tenes 496797 paginas de 4K c/u libres para guardar datos de Guarani, o sea esta casi todo sin usar (son aprox 2Gb libres)

Por lo tanto al parcer esta todo bien. Fijate si desde alguna operacion del guarani se ven datos , porque el dbspace esta muy vacio

No hay ningun problema que las preguntas vayan mutando cambiando, solo que queria entender porque habiamos pasado a otro tema y en que situacion habia quedado el tema anterior.

saludos
Ignacio

Hola Ignacio.
Como te va?
Los problemas sobre el informix se mantiene, por ende decidimos continuar con la versión que tenemos, hasta que termine las clases o pasen todas las mesas de exámenes y ahí utilizar el razor para ir sacando manualmente todos los datos de cada una de las tablas correspondientes al dba, e ir importándolas a otro informix que esta funcionando bien. Pensamos que es la alternativa más viable al dbexport que no funciona.
Por otro lado te quería consultar, que al momento de ejecutar el comando “onstart -l” se obtiene un informe de los log y su disponibilidad en uso, luego ejecuto el comando “ontape -a” para su correspondiente limpieza de aquellos log que estén completos para liberarlos, mi consulta va por los correspondiente “ID” que se observan en el lisdato frente a los que arroja el ontape. Tiene alguna idea del porque el ontape al finalizar arroja un ID que no figura en el listado?
En este hilo hice la consulta pero no se si existe un motivo por dicho error si es que tiene error.
https://foro.comunidad.siu.edu.ar/index.php?topic=25224.0
Allí veras dos imágenes donde se observa esa situación.
Saludos y desde ya agradezco tu predisposición a responder cada duda que planteo.

                                                                                                                                                        Cesar

Hola. Retomando de nuevo este hilo y ara darle un fin. Para solucionar el tema de los índices y que no respondía el dbexport lo que se hizo fue por un lado para el tema de dbexport, eliminar todos los sp y provee a correr de nuevo el comando, como lo pude hacer, comencé a crear de nuevos los sp por grupos de 10, luego de 20 y por cada regeneración de sp corrí el comando de dbexport, lo hice tantas veces hasta que pude generar de nuevo todo el script con la base de datos completa con todo los sp borrados.
La segunda etapa de los índices no me quedo otra que ir corriendo el script generado en otra virtual e ir analizando los errores que se iban generando al momento de insertar los datos en las respectivas tablas y luego en las claves foráneas.
La mayoría de los errores que se me presentaron fueron en las tablas de log, algunos los pude salvar y otros directamente los saque del archivo y quedaron en pendientes a revisar el motivo del porque no se los puede ingresar siendo que los datos estas correctos a nivel estructural.
Recomiendo que al momento de ir abriendo los archivos que van dando errores en el contenido de abrirlos con el correspondiente set de caracteres o encoding que es el “Westem (Windows 1252)” ya que sin esta previa configuración los caracteres especiales los cambia el editor que usen para arreglar el error.
Y armarse de mucha paciencia para tratar estos errores.
Saludos Cesar!!!

Hola.
Retomando este hilo el problema ya fue resuelto.
Saludos!!!