Buenos días, me encotré con un problema que ya se comento el foro respecto al dbexport cuando no termina de completarse.
Siguiendo las sugerencias del foro empece a borrar el SP siguiente al ultimo que exporto y luego corría un update statistics for procedure.
De esta manera empezó a exportar mas cantidad de SP, pero aun asi no termina por completo.
La pregunta es la siguiente debido a que son muchos los “Illegal SPL Routine Entry” cuando genero el “dbschema -f all -d basedatos”
Hay alguna forma de regenerar los SP masivamente sin tener que borrar uno por uno?
-c - CheckOption
r - reserved pages
R - reserved pages including logical and physical logs
e - extents c - database catalogs [database]
i - table indexes database[:[owner.]table[#index]]
I - table indexes and rowids in index database[:[owner.]table[#index]]
x - place share lock on table during index check
d - TBLspace data rows including bitmaps
database[:[owner.]table[,fragdbs]]
D - TBLspace data rows including bitmaps, remainder pages and BLOBs
database[:[owner.]table[,fragdbs]]
s - SBLOBspace metadata partitions
S - SBLOBspace metadata partitions and LO extents
1-Hasta ahora todos los backups los venimos haciendo con dbexport a secas si ninguna opcion de las que mencionas y siempre terminaban bien. Me recomendas que le agregue alguna variante?
2-Probé corriendo los siguientes comandos de oncheck pero solo salen warnings:
“WARNING: index check requires a s-lock on tables whose lock level is page.”
No logro determina cual es el SP que esta molestando, probe borrando y creando nuevante los SP anterior y siguiente a donde se corta el dbexport pero no termino de repararlo.
Probe con:
C:\INFORMIX>dbschema -f all -d agrarias > sp270.sql y tambien se corta con el mensaje: “Illegal SPL Routine Entry.”
Yo recuerdo un problema con los comentarios…
El problema se originaba con el eSQLEditor que permite poner comentarios antes del CREATE PROCEDURE y esos comentarios rompen la exportación.
En su momento lo que hice fue buscar en los sysprocbody.data los pedazos de texto que correspondían a un comentario anterior al CREATE PROCEDURE y “moverlos” (desde el eSQLEditor) para que lo primero sea CREATE PROCEDURE lalalala(…). Corregido eso el dbexport siguió funcionando de maravilla.
Lo que no recuerdo es si cualquier comentario rompía la exportación o si solo eran los del tipo /* comentario */ pero me parece que eran solo estos últimos los del conflicto. (osea que los comentarios que empiezan con – creo no rompían nada).
Como sea, si usan el eSQLEditor y pusieron comentarios antes de los CREATE ALGO sepan que ahí el dbexport no sabe que hacer con esos comentarios (no sabe si son comentarios del objeto anterior o del siguiente y explota).
Para que los oncheck no te de ese error debés correrlos con el parámetro -x, además de los otros parámetros, para que el oncheck realice un bloqueo compartido sobre la tabla durante el chequeo de los índices y de esa manera o te da más ese mensaje.
Lo que daba error al realizar el dbimport eran unos comentarios como ser: – var’s …
Esa comilla en ese texto daba el error al importar una base.
Se arreglaba cambiando – var’s por – vars en el sql del export.
Pero en este caso el error te lo da al exportar la base, es decir el problema hay que solucionarlo como indica Diego en la base antes de realizar el export.
Buenos dias, ahi subi el dbexport.out y las salidas del oncheck.
Lo raro es que tenemos varias BD y todas tienen los mismos SP de creacion y en la mayoria termina de correr el backup correctametne.
Hola Si el dbexport se corta en los procedures, algo esta mal en la base. ASi que para mi hay que crearla desde 0 nuevamente.
asumo que al cortarse en los procedures todas las tablas, y datos deberian estar exportados OK
En ese caso, lo que haria a continuacion seria exportar solo los procedures usando un dbschema
y luego renombrar la base actual para mantenerla como backup e importar la base del dbexport trunco (ese dbimport no va a importar los procedures) y por ultimo importar los procedures del archivo resultante del dbschema.
Tu respuesta sería correcta si no fuera que se te escapa un detalle no menor, que ocurre en Windows (no sé si en Linux): el export lo primero que hace es exportar los SP, por lo tanto si se le corta en algún SP NUNCA le llega a exportar los datos, por lo cual debería buscar otra manera de bajar los datos, haciendo un unload de cada una de las tablas para después hacer un load, todo lo cual por cierto es una tarea re-tediosa.
Si esto es lo que le pasa, mi recomendación sería hacer un DROP de cada uno de los SP para que le quede la base sin SP y solo con datos + triggers + vistas y recién ahí hacer el export y ver que pasa, para luego importar solo los datos y luego recrear todos los SP según las indicaciones de respuestas anteriores.
Lo que si definitivamente estoy de acuerdo contigo es que el problema es en la base, o en ese motor si las demás bases estuvieran en otros motores Informix.
Quizás una consulta parecida a la que les comparto los ayude un poco:
select * from sysprocedures where procid in (
select procid from sysprocbody
where (substr(trim(data),0,2) in (‘/*’,‘–’) or
substr(trim(data),0,1)=‘{’) and seqno=1 and procid in (
select procid from sysprocedures where owner=‘dba’
)
)
No digo que todos esos SP rompan el dbexport, pero seguro seguro que uno de esos es…
no recuerdo exacto cual era el error que detonaba al backup como para hacer un filtro más preciso, pero espero que les sea útil.
1- El sp_int_arau_ccu_14 no lo tengo en el catalogo de SP de la base.
2- El comando dbschema -d agrarias esquema_agrarias.sql se corta en el mismo punto que el dbexport que seria en el SP “sp_int_arau_ingnui”. y el mensaje que tira es “Illegal SPL Routine Entry”
3- Ya corri oncheck -cc agrarias y UPDATE STATISTICS FOR PROCEDURE; y sigue todo igual al exportar.
Respecto de los que dice Ignacio, el dbexport genera primero los Create de las tablas y los archivos .unl OK, despues es cuando se corta sobre el final de los SP.
Probe restaurar los datos por separado con dbimport y los SP desde sqleditor con un catalgo completo que tengo y funciona perfectamente, pero como es la base de datos operativa estaba buscando alternativas para no sacar de linea el servicio.
Tambien probé borrando el SP siguiente en donde se cortaba y creandolo nuevamente y así pudo avanzar el dbexport casi por completo, pero ahora estoy parado en el SP sp_int_arau_ingnui y no logro avanzar.
Si este error del dbexport deberia repercutir en el funcionamiento de Gestion hasta ahora no se
reportaron fallas en el uso y el sistema funciona perfectamente.
Esta bien si no tenes el procedure sp_int_arau_ccu_14 porque fue creado en la version 2.8.0. Estaba viendo un export de esta version por eso era el procedure que se creaba a continuación del sp_int_arau_ingnui.
Probaste borrar el procedure sp_int_arau_ingnui y realizar el dbexport nuevamente o se corta en el siguiente procedure?
Veo que tenés la suerte que lo que exporta primero son los datos!!
En ese caso yo seguiría al pie de la letra las indicaciones de Ignacio y los SP los regeneraría tomándolos del último dbexport bueno que tengas. En una situación así, a lo sumo deberías regenerar a partir del catálogo algún SP si te falta.
Otra posibilidad que se me ocurre es, teniendo en cuenta hasta donde llegaste y los SP que parecen estar jorobando, eliminar todos los SP de la interfase araucano (sp_int_arau …) y ver si así termina bien el export. Y si termina bien, luego regenerarlos del catálogo de la versión o del último export bueno.
Hola Gustavo, la única solución que encontré es restaurar con dbimport la parte de los datos solamente que si llega a exportarse correctamente y después con un archivo separado corro todos los script de creación de SP en el SqlEditor.
Mi idea era intentar con algún comando informix para no tener que restaurar la BD entera pero nada me dio resultado.
Saludos para todos y muchas gracias por las sugerencias.