Obtener el DTS de un paso de un job.

Hola este sera un post pequeño, per me parecio muy util y es que tengo un servidor SQL Server 2000 (si ya se que es bastante antiguo pero es lo que hay), entonces en este servidor hay jobs los cuales dentro de sus steps ejecutan paquetes DTS, sin embargo cuando se abre el step para ver su contenido se ve una sentencia encriptada como la siguiente:

DTSRun /~Z0x6078C236DCDD6A73931306866F9FC179EF750F439603F2CBEB820803744FC6605FF904C2DC6A6F355026A4CF56DEE2CBC7E72D6E7C1C88F17EA6CD17AEA6D7B6D6234D8D743CB0619D8A52006060594AEFEF6EC6582531B5DA1D1F30EDA8B8E2E78099A7869557567EF93557F67265092AF0F4 

Entonces, el problema esta en identificar que DTS es el que ejecuta el step. Luego de buscar puede ver que es tan simple como seguir los siguientes pasos:

  • Abrir una ventana de comandos en el servidor donde se alojan los paquetes.
  • Pegar toda la cadena antes mencionada
  • Agregar al final de esa cadena lo siguiente “/!X /!C”. Entonces quedaria como sigue:

DTSRun /~Z0x6078C236DCDD6A73931306866F9FC179EF750F439603F2CBEB820803744FC6605FF904C2DC6A6F355026A4CF56DEE2CBC7E72D6E7C1C88F17EA6CD17AEA6D7B6D6234D8D743CB0619D8A52006060594AEFEF6EC6582531B5DA1D1F30EDA8B8E2E78099A7869557567EF93557F67265092AF0F4 /!X /!C

Luego de ejecutar la cadena se copiara a la memoria el texto desencriptado de la ejecucion del paquete, entonces solo hay que abrir un notepad y pegar (CTRL + V) y se obtendra algo asi:

DTSRun /S “MiServidor” /N “MiPaqueteDTS_SQL2000” /E /!X /!C 

Y eso es todo, con eso se puede saber con seguridad cual es el paquete que ejecuta un paso de un job. Espero que les sea de utilidad.

Anuncios

Diseño de una Base de Datos

Las Bases de Datos están compuestas por elementos lógicos y físicos como se puede detallar en el siguiente post. Sin embargo para poder tener un mayor control sobre los objetos que guardamos en ella es necesario realizar un planeamiento previo del diseño ésta, este paso previo a la creación de la base de datos es muy importante ya que si no tenemos un buen diseño inicial, mas adelante cuando encontremos problemas en el diseño, el corregirlo será mucho mas complicado y costoso.

 Comenzaremos viendo desde donde sale la estructura inicial de una base de datos en SQL Server. Cuando se crea una base de datos, internamente SQL Server toma como plantilla la base de datos de sistema llamada “model”, heredando todas sus propiedades y objetos, también copiando los filegroups y datafiles para luego cambiarles de nombre por los de la nueva base de datos, sin embargo este diseño lógico y físico inicial se puede personalizar añadiendo opciones adicionales a la creación de la base de datos, estas opciones adicionales se pueden agregar a través de código o a través del wizard del SSMS (SQL Server Management Studio).

El problema con esto es que normalmente la base de datos model esta configurada sólo con el filegroup “PRIMARY” con un tamaño de 8 MB y un Log de transacciones de 2 MB, ambos configurados con un auto-creacimiento de 10% para ambos archivos. Adicionalmente tiene un modelo de recuperación Full, lo cual ocasiona problemas con el crecimiento del log de transacciones si es que éste no tiene el tratamiento debido, es decir considerar dentro de la estrategia de backup los backups de log de transacciones, lo cual normalmente.

Ahora, personalmente considero que toda base de datos debe tener por lo menos dos filegroups, uno de ellos siempre sera el “PRIMARY” el cual albergara a todos los objetos de sistema como las tablas y vistas de metadata, los subsiguientes filegroups serán dedicados a albergar la data del usuario. Adicionalmente se pueden agregar mas filegroups que sirvan para albergar distintos tipos de data como indices, BLOB data, o tablas de módulos específicos. De esta manera,al tener filegroups destinados a un uso especifico es mucho mas ordenado e incluso permite traer a la base de datos en linea por partes en caso de algún desastre reduciendo el tiempo de espera de los sistemas para poder acceder a la data.

Otra razón importante para poder tener este diseño es para tener mayor flexibilidad al momento de mover los datafiles de un disco a otro mientras estos se encuentran en linea, si es que la data de usuario se encontrara en el filegroup ”PRIMARY” y se quisiera mover el data file con extensión “MDF”, no se podría mover ya que este datafile en especial no puede ser vaciado por completo. Mas adelante tendremos un articulo en el cual se explicara a mas detalle como se debe hacer este movimiento.

Finalmente el realizar este diseño permitirá que la data se distribuya entre varios archivos de datos los cuales según las buenas practicas deberían estar alojados en diferentes discos físicos los cuales permitirán compartir las operaciones de lectura \ escritura de disco, lo cual permitirá el más rápido acceso a los datos. Así que ya saben la próxima vez que se cree una base de datos piense bien el mejor diseño que esta debe tener.