Archivo de Julio de 2008 Este Artículo presenta un problema típico asociado a los Procedimientos Almacenados con Parámetros y la generación del Plan de Ejecución (compilación) y la reutilización del Plan de Ejecución generado (pues el Plan de Ejecución se almacena en caché y se intenta reutilizar). Se trata del problema de Parameter Sniffing. Del mismo modo, se explican distintas soluciones: utilizar variables locales (DECLAREs), utilizar SQL Dinámico con sp_executesql ó EXEC(@sql), utilizar WITH RECOMPILE al invocar al Procedimiento Almacenado, utilizar la sugerencia de consulta WITH(RECOMPILE), utilizar la sugerencia de consulta WITH(OPTIMIZE FOR), utilizar la sugerencia de consulta USE PLAN, utilizar Plan Guides (sp_create_plan_guide), etc. Ya me ha hecho falta varias veces acceder a Informix a través de ODBC de 64-bit y MSDASQL de 64-bit desde servidores Microsoft Windows 64-bit (desde SQL Server 2005 64-bit con OPENROWSET u OPENQUERY a través de Servidores Vinculados - Linked Servers). Esta tareas ya es posible, tanto por la disponibilidad de Driver ODBC 64-bit para IBM Informix (ej: IBM Informix Client Software Development Kit 3.50.FC3) como por la disponibilidad del Proveedor MSDASQL de 64-bit (proveedor puente OLEDB a ODBC), ambos disponibles desde hace pocos meses. En este Artículo relato los detalles a tener en cuenta para poner en marcha dicha configuración de acceso a base de datos. Hace ya tiempo que necesitaba un cambio. Total, desde Junio de 1994 sólo he atravesado dos empresas (algo poco habitual en mi sector), y desde el 1 de Julio de 2008 empiezo una nueva aventura en una tercera compañía, en esta ocasión centrado al 100% en Soluciones de Business Intelligence de Microsoft (aunque quizás trabaje con algún otro fabricante, pero Microsoft - y SQL Server - es mi claro objetivo en tecnología). Tengo que agradecer la pequeña despedida que me hicieron los compis, sus dedicatorias, y el Grifo de Cerveza Princes para Barriles de Cerveza Heineken que me regalaron (¿tanto se me nota?). Y sobre todo, tengo que agradecer su completa sumisión, que llevan aguantándome ya un tiempecito (mis bromas incluidas) ! Cada día es más habitual necesitar consultar orígenes de datos ODBC (DSN) desde SQL Server 2005, ya sea para importar, para exportar, o simplemente consultar dichos datos. Esto se hace en muchos casos utilizando el proveedor MSDASQL, que se trata de un proveedor OLEDB para acceder a orígenes de datos ODBC (es decir, es un puente OLEDB a ODBC), y en SQL Server utilizar OPENROWSET o un Servidor Vinculado (Linked Server) y OPENQUERY para acceder a dicho origen de datos (DSN). De hecho, este proveedor OLEDB (MSDASQL) también se utiliza en Aplicaciones Web y WinForms, etc. Sin embargo, "de serie" sólo existe la edición MSDASQL de 32-bit. Por ello, si una instalación de SQL Server 2005 64-bit sólo puede acceder a los proveedores OLEDB de 64-bit registrados en dicho servidor ¿Qué hacer para consultar un origen de datos ODBC a través SQL Server 2005 64-bit? Este Artículo pretende mostrar las consideraciones a tener en cuenta para diseñar un Plan de Contingencias (una recuperación completa) de BusinessObjects Enterprise XI R2 o con BusinessObjects Enterprise XI (sin el R2 ;-). ¿De qué es necesario realizar copia de seguridad (Backup) en BusinessObjects Enterprise XI R2? ¿Qué pasos se deben seguir para recuperar nuestro servidor BusinessObjects Enterprise XI R2? ¿Y si teníamos personalizado InfoView? ¿Y si necesitamos recuperar en otro servidor? Quizás no sea éste el mejor método, pero lo que si puedo asegurar, es que ha funcionado ;-) Ah! Y no es un método soportado... aunque funciona ;-) |
