Antes de comenzar la implementación del proceso ETL para la carga de la tabla de Hechos de Ventas, vamos a realizar alguna consideración sobre el particionado de tablas.
Cuando estamos costruyendo un sistema de business intelligence con su correspondiente datawarehouse, uno de los objetivos (aparte de todas las ventajas de sistemas de este tipo: información homogenea, elaborada pensando en el analisis, dimensional, centralizada, estatica, historica, etc., etc.) es la velocidad a la hora de obtener información. Es decir, que las consultas se realicen con la suficiente rapidez y no tengamos los mismos problemas de rendimiento que suelen producirse en los sistemas operacionales (los informes incluso pueden tardar horas en elaborarse).
Para evitar este problema, hay diferentes técnicas que podemos aplicar a la hora de realizar el diseño fisico del DW. Una de las técnicas es el particionado.Pensar que estamos en un dw con millones de registros en una unica tabla y el gestor de la base de datos ha de mover toda la tabla. Ademas, seguramente habrá datos antiguos a los que ya no accederemos casi nunca (datos de varios años atras). Si somos capaces de tener la tabla “troceada” en segmentos mas pequeños seguramente aumentaremos el rendimiento y la velocidad del sistema.
El particionado nos permite distribuir porciones de una tabla individual en diferentes segmentos conforme a unas reglas establecidas por el usuario. Según quien realize la gestión del particionado, podemos distinguir dos tipos de particionado...

A continuación dejo un par de ejemplos de como funciona el backup simple de sqlserver 2008 y como hacer un restore. En el primer ejemplo hacemos un drop de la base de datos que en un entorno real puede significar la perdida de un datafile o disco etc etc. El segundo ejemplo es algo más rebuscado y lo que se hace es restaurar la copia de la base de datos para recuperar una tabla y extraer sus datos. En ambos ejemplos se trabaja con bases de datos de ejemplo descargables aquí.

Para aquellos administradores de bases de datos que deban tratar con un tal Dynamics Ax 2009 y sus secuaces (desarrolladores, consultores, etc ) dejo aquí un par de cosillas que se deben saber(o te deben decir) cuando unimos ax2009 y sql server 2008. A veces se puede apuntar a la base de datos como fuente del problema pero no siempre es así.  Algunos requerimientos a tener en cuenta para la instalación de Ax2009 son que el usuario con el que quieran acceder para hacer la instalación debe ser usuario de DOMINIO y en sql server debe ser miembro de rol dbcreator y securityadmin para poder crear la nueva base  de datos desde el instalador de Ax. Una vez instalado (o durante el proceso de instalación) los problema con la base de datos que nos podemos encontrar pueden ser:

Caso 1:
Otro problema conocido en la sincronización de datos puede producirse por la falta de permisos. El mensaje dice algo así:

Una manera muy simple de exportar datos de una consulta, tabla, etc. de una base de datos oracle a un fichero plano es utilizar el comando SPOOL de SQLPlus. De esta manera no es necesario depender de herramientas visuales, que no siempre están disponibles, o no siempre funcionan como queremos.

Además, se pueden utilizar las funciones de formato de Oracle en la misma sentencia SELECT para que los datos se generen ya en el formato que necesitemos.

Ejemplo de exportación de datos a un fichero plano desde SQLPlus

Si, por ejemplo, queremos recuperar algunos datos de todos los registros de una tabla de clientes ordenados por fecha de alta, sólo hay que abrir una sesión de SQLPlus y ejecutar esta serie de comandos:

Normalmente para analizar lo que pasa unas horas antes bastaría con consultar los datos históricos del Enterprise Manager pero no tenemos datos como el detalle de sesiones activas (si la cantidad total) o el estado o programa de cada una de ellas. También consultar las instantáneas en la consola web pero el problema sigue siendo el mismo, la falta de detalle. Pero no todo es insalvable y podemos en tres pasos completar esta información con algo más de detalle.

Paso 1: Crear una tabla con los datos que necesitaremos con un campo fecha.

Paso 2: Crear un procedimiento para alimentar la tabla con datos.

Paso 3: Crear un job con el usuario indicado para acumular datos.

Esta técnica puede ser “cutre” pero muchas veces sirve para analizar con más detalle y a nuestro gusto ciertas estadísticas que son visibles mediante vistas v$ que muestran el estado actual de la base de datos y que directamente no muestran un estado anterior en el tiempo.

Por fin hemos terminado con la publicación del manual online sobre Bases de datos, material docente editado por la UOC para su Master de Software Libre.

Comentábamos su contenido en el post Material sobre bases de datos 'libres', Master de la UOC.

Como podréis ver en los contenidos es un material docente de gran calidad, donde se pueden encontrar tanto los conocimientos teóricos necesarios para entender y trabajar seriamente con cualquier tipo de base de datos relacional como conocimientos más técnicos y específicos para manejarse con bases de datos Open Source como MySQL y PostgreSQL. Altamente recomendable.

Agradecemos a la UOC que hayan sido consecuentes con la filosofía abierta del master que están impartiendo y hayan publicado el documento bajo una licencia GNU

Pasos que sigue Oracle para procesar una consulta:

1) Validación Sintáctica
2) Validación Semántica
3) Optimización
4) Generación del QEP (Query Execution Plan)
5) Ejecución del QEP (Query Execution Plan)

En algunos entornos nos podemos encontrar con aplicaciones que realizan ciertas consultas (y digo consultas) de forma muy reetiva de forma continua. Cuando el catálogo es muy amplio, continuo e inevitable debemos tener en cuenta dos parámetros de inicialización de la base de datos: open_cursors y session_cached_cursors.

Open_cursors nos permite establecer el límite de cursores por sesión y su seteo es muy directo. Si se necesitan 1000 y no hay nada que optimizar pues 1000 pondremos. En cambio Session_cached_cursors es algo más complejo y requiere analizarse en base al número máximo de cursores (open_cursors) y la cantidad actual de cursores que se mantienen en "cache" actualmente.

Consulta:

Se puede dar el caso que necesitemos acceder a MySql desde Sql Server 2008. Para hacerlo podemos crear un servidor vinculado que use una conexión odbc. Como hacerlo paso a paso:

1. Descargar el cliente ODBC de Mysql para la plataforma del sevidor sql. Lo podeis hacer aquí.

2. Instalarlo (siguiente, siguiente, siguiente) y configurar un DSN de sistema. Para ello en el Administrador de orígenes de datos ODBC, en la pestaña DSN de sistema pulsamos Agregar y seleccionamos MySQL ODBC 5.1 driver. Acepatemos y aparece un formulario como el siguiente. Lo rellenaremos y probaremos pulsando Test para comprobar que funciona.

3. Añadir el servidor vinculado en la base de datos. Para ello nos conectamos a la base de datos y en el árbol de objetos vamos a  Objetos de servidor, pulsamos botón derecho en Servidores vinculados y clickamos en Nuevo Servidor Vinculado, rellenamos los datos y ya lo tenemos.

Dado que es algo que se suele repetir y ya me lo han comentado más de una vez, creo oportuno crear un post donde se describa el problema y la solución en Sql server 2008 para newbies. Más que nada para que no perdaís tiempo buscando...

Problema:
Al modificar el tipo de campo en una tabla ya creada (pero vacía) o al añadir alguna clave foránea me aperece un mensaje como el siguiente:"No se permite guardar los cambios. Los cambios que ha realizado requieren que se quiten y se vuelvan a crear las tablas".