Hasta el momento desconozco exactamente como o donde se detalla cada tipo de error en la ejecución de un informe de reporting services de Microsoft SQL Server. He tratado con derivados de falta de permisos, procesados incompletos de cubos pero hasta ahora ningun #Error en una celda por que sí.

El error en cuestión me aparece en la ejecución de un pequeño informe que tira de un origen de datos ODBC contra una base de datos Oracle donde se muestran totales (sumas, no porcentajes) y me ha sorprendido mucho la falta de detalle sobre el error que se produce. Para más dificultad, encima es en una combinación de parámetros concreta (las n ejecuciones anteriores han funcionado) y no en toda la columna sino en una celda. Además arrastra todo subtotal o total en el que se incluya...

Siguiendo con el post anterior creo necesario comentar que existen otros tipos de bloqueo que se producen por un diseño conflictivo que se une a las peculiaridades de oracle.

Dejo primero la traza de ejemplo:

La fragmentación tiene lugar sobretodo en tablas donde hay mucho movimiento insert/delete. Este crece mucho cuando el volumen de datos de la tabla es muy variable en el tiempo: por ejemplo en tablas de control de transacciones, de logueos de usuarios, de tablas intermedias, etc. El primer sintoma de fragmentación sería lentitud en las consultas, principalmente perceptible en tablas con muchos registros..

Con SQL Server podemos caer muy fácilmente en lo que se dice habitualmente sobre los productos Microsoft "Siguiente, siguiente y listo". No vamos a negarlo, Microsoft consigue hacer que gente sin mucha idea salga adelante y es todo un mérito. Pero vayamos al tema. Si se empieza una nueva aplicación y tenemos que crear la estructura de datos, no dejemos solos a los desarroladores y tampoco que usen el MS Management Studio. Normalmente, en lo que a la base de datos se refiere, cuando se crean se tienen en cuenta varias cosas...

La cláusula loggin/nologging añadida cuando creamos una tabla, índice, tablespace... determina si se crea registro de la sentencia en los redo log y su correcta restauración desde backup. Tiene guasa porque si creamos una tabla con opción nologging efectivamente no se crea registro pero de alguna manera esta si se tiene en cuenta en el diccionario de datos.
Al terminar la recuperación los bloques correspondientes a la tabla/índice son marcados como corruptos y cuando intentemos acceder obtendremos un error como el siguiente...

Hay gente a favor y en contra de esta herramienta pero para mí resulta de lo más útil para tareas concretas y como complemento. Con el paso del tiempo la he usado alternándola con otras herramientas y "trabajos manuales" y hasta el momento no hay nada que haya hecho de con otra cosa que no pueda hacer con TOAD.

En este caso comento como buscar actividad "extra-ordinaria" en nuestra base de datos con TOAD...

Cuando se produce este error el listener de nuestra base de datos Oracle está rechazando conexiones y no nos podemos conectar de ninguna manera con la base de datos. Para ver que está pasando podemos consultar el log del listener en /opt/oracle/product/10.2/db_1/network/log/listener.log para ver que nos cuenta el sistema. En el caso que nos ocupa podemos encontrar una entrada como la siguiente:

"TNS-12518: TNS:listener could not hand off client connection"

...

Por la razón que sea puede que tengamos que desarrollar un paquete de Microsoft Integration Services que nos mueva datos de cualquier origen a una tabla que se encuentra en una base de datos MySQL.
La primera intención será hacerlo mediante una ADO.NET Destination y el provider de MySQL para la conexión. Si lo hacemos así para insertar los datos directamente, al crear el destino, seleccionar la conexión y luego seleccionamos la tabla aparecerá un error como el siguiente al comprobarlo todo con la vista previa o al intentar hacer las asignaciones.

Este error se debe a al modo de compatibilidad sql ansi de la base de datos mysql donde intentamos cargar los datos. Para solventarlo debemos conectarnos al servidor de MySQL y cambiar la compatibilidad ansi de sql de la base de datos*...

Dejo aquí este link a una página donde plantean un pequeño test que hacer en las entrevistas de trabajo para desarrolladores de bases de datos. Aquí este tipo de test no creo que se estile mucho en una entrevista de trabajo, pero más de una incorporación al departamento de desarrollo debería evaluar sus conocimientos con un test similar. Más que nada para evitar cracks, máximos de conexiones, diseños de tabla si claves primarias, etc... En este otro site también han hecho un test equivalente para evaluar conocimientos de SqlServer...

El modo archivelog de una base de datos Oracle protege contra la pérdida de datos cuando se produce un fallo en el medio físico y es el primer paso para poder hacer copias de seguridad(en caliente!!) con rman. Para poner la base de datos en modo archivelog (sin usar la flash recovery area) debemos hacer básicamente dos cosas, añadir dos parámetros nuevos al fichero de configuración, reiniciar la base de datos y cambiar el modo trabajo a archivelog.

Como poner la base de datos Oracle 10g en modo archivelog

1. Editamos el init.ora para añadir los siguientes parámetros
   *.log_archive_dest='/ejemplo/backup/'
   *.log_archive_format='SID_%r_%t_%s'
   .....