martes, 1 de septiembre de 2009
Cambiar el idioma por omisión de tu motor SQL Server
SELECT @@LANGUAGE AS 'Language Name' -- Este comando es para saber en que lenguaje se encuentra.
SET LANGUAGE Spanish
exec sp_defaultlanguage sa, 'spanish'
Luego de eso, reinicia el servidor y listo. Nos vemos.
jueves, 13 de agosto de 2009
Reiniciar campo tipo identity para SQL Server
Lo hacemos con un comando DBCC:
DBCC CHECKIDENT (nombre_tabla, RESEED,0)
Solamente coloquen el nombre de la tabla y listo. Nos vemos.
jueves, 18 de junio de 2009
Nueva opción de conocimiento
lunes, 15 de junio de 2009
SQL Server Tips 002: Consultas ad-hoc como cadenas.
DECLARE @x AS VARCHAR(100)
DECLARE @y AS DATETIME
SELECT @y = GETDATE()
SELECT @x='SELECT CAST(''' + CAST(@y AS CHAR(10)) + ''' as CHAR(10))'
EXEC(@x)
jueves, 28 de mayo de 2009
Strategies for Partitioning Relational Data Warehouses in Microsoft SQL Server
Revísenlo vale la pena.
miércoles, 27 de mayo de 2009
Modelo de encripción de datos: SQL Server 2008 II Parte
Como veremos las nuevas características de SQL Server 2008 incluyen una muy importante, llamada Transparent Data Encryption la cual puede ser usada para encriptar dichos respaldos.
A continuación les mostraré como implementar una encripción para proteger los respaldos. Pero primero veamos que podemos consultar un registro en la base de datos:
BACKUP DATABASE AdventureWorks TO DISK = 'C:\AdventureBCK.bak' WITH INIT, STATS = 10
Modelo de encripción de datos: SQL Server 2008

martes, 26 de mayo de 2009
Temporary tables vs table variables

El considerar usar una u otra dependerá de las necesidades inmediatas, muchos echan por la borda las tablas temporales desde el primer momento, pero veremos que las cosas existen para cubrir una necesidad de información, que muchas veces es blanca y otras negra.
Cosas importantes a considerar:
- Al igual que una tabla temporal local, una variable table solo puede ser utilizada por la sesión que la creo, pero esta es más limitada ya que solo puede ser vista por el batch donde fue creada y una vez finalizado el batch es destruida automáticamente.
- Las variables table no contienen estadísticas como las tablas temporales, este uno de los factores más importantes a considerar, ya que sin estas estadísticas SQL Server no puede tomar una buena decisión a la hora de generar el plan de ejecución. Aunque esto puede dejar de ser importante si la cantidad de información que vamos a manejar es muy pequeña.
- Las tablas temporales debido a que usan estadísticas, generan recompilaciones, cosa que no pasa con las variables table.
- Los cambios realizados sobre una variable table, no son tomados en cuenta en las transacciones, por lo que si una operación es terminada a la mitad que involucre cambios a una variable table, el rollback no se lleva a cabo en la variable table.
- Las variables table, generan menos bloqueos y hacen menos uso del log de transacciones, pero existe una excepción, ya que no es posible hacer uso de un SELECT INTO en las variables table, por lo que en este caso cuando se inserta información en una variable table se realizan más operaciones en el log de transacciones que en una tabla temporal, que si puede hacer uso del SELECT INTO.
En resumen, cuando estemos utilizando pocos registros es mejor usar variables table, pero cuando vamos a hacer uso de muchos registros, primero debemos verificar que tipo de queries vamos a ejecutar, si son queries que no requieren de estadísticas se va a tener un mejor desempeño con las variables table, pero si los queries requieren de las estadísticas es mejor el uso de tablas temporales. Nos Vemos.
SQL Server Tips 001: ESTIMATEONLY option

Espero les guste este nuevo tipo de post que pienso agregar de hoy en adelante. s tratarán de tips cortos de desarrollo, administración, tunning, etc. que me sepa o encuentre en internet sobre SQL Server, ahí les va el primero:
Antes de ejecutar un DBCC asegúrate que tienes suficiente espacio en TEMPDB. Se puede usar la opción ESTIMATEONLY para conocer el espacio que vas a requerir al ejecutar un comando DBCC CHECKDB, DBCC CHECKTABLE, DBCC CHECKFILEGROUP y DBCC CHECKALLOC.
domingo, 12 de abril de 2009
IBM MQSeries con .NET 2008 - II Parte
Recordemos que un mensaje consiste del control de la información y los datos de la aplicación. El control de la información en una estructura descriptora de mensaje (MQMD) contiene lo siguiente:
- El tipo del mensaje.
- El identificador del mensaje (muy importante cuando se usa grouping) .
- La prioridad de envío del mensaje.
¿Qué es una cola de mensajes?
Una cola de mensajes, llamada simplemente cola, es un encapsulamiento por el cual los mensajes pueden ser enviados. Los mensajes pueden ser almacenados en colas hasta que son devueltos por los aplicativos que dan el servicio a esas colas. Las colas residen y son administradas por un administrador de colas. Una cola también puede ser un área de buffer volátil, o un conjunto de datos permanente en un dispositivo de almacenamiento, como un disco. La administración física de colas es responsabilidad del administrador de colas y no de los aplicativos participantes.
Los aplicativos pueden acceder a las colas solamente a través del administrador de colas (de hecho, no habría forma física de acceso de nos ser así), debido a que éste objeto es el lleva las credenciales de acceso del usuario, el puerto y el canal en una tabla hash o por directivas de ambiente. De esta manera se pueden llevar a cabo operaciones como, abrir una cola (open), colocar mensajes (put), obtener mensajes de respuesta (get), y cerrar colas (close). Además, se pueden "setear" los atributos de las colas, por decir, el formato, la conversión de datos, las banderas de comportamiento, etc.
¿Qué es un administrador de colas?
Es un componente que provee servicios de colas a las aplicaciones. El cual, expone un API que permite colocar (hacer put) y obtener (hacer get) mensajes hacia y desde las colas. Un administrador de colas provee funciones adicionales para crear nuevas colas, modificar las propiedades de las existentes, y controlar la operación de éstas.
Para que los servicios de mensajería de colas estén disponibles en un sistema; debe haber un administrador de colas corriendo sobre un sistema operativo compatible, tales como: OS/400, z/OS, OS/2, Windows, UNIX o Linux. También se puede tener varios administradores de colas corriendo en un mismo sistema (para escenarios de prueba y producción por separado). Se debe tener en cuenta que para cada aplicativo, cada administrador de colas es identificado por un connection handle (Hconn) propio.
Muchos aplicativos diferentes pueden hacer uso de los servicios de administración de colas al mismo tiempo y no estar relacionados unos con otros, ni en tecnología, ni en función u objetivos.
Para que un aplicativo use estos servicios, debe establecer una conexión al administrador de colas (con los datos adecuados obviamente). Además, para que éstos puedan enviar mensajes entre aplicaciones, todos los administradores de colas deben comunicarse entre sí, por canales en común ya establecidos. WebSphere logra esta implementación debido al protocolo de almacenaje y envío (store-and-forward protocol), el cual asegura la entrega de los mensajes debido a que es orientado a conexión.
Nos queda poco por cubrir con respecto a definiciones, así que, preparados porque ya casi vemos código. Nos vemos.
viernes, 3 de abril de 2009
Comprimir TempDB en SQL Server
Encontre dos maneras (lo que indica que no existan más formas) de realizar esa tarea, los describo de seguido.
Según leí, Microsoft desestima comprimir cualquier TempDB que este siendo usada constantemente. Esto es porque "you may receive multiple consistency errors" que podrían no solamente interrumpir actividades de usuarios cuando se da la operación de compresión. Sin embarga esa actividad normalmente es mínima o nula, en todo caso, aquí están los pasos:
- Corra el comando DBCC SHRINKFILE en cada archivo que usted quiera reducir el tamaño:
USE TempDB
GO
DBCC SHRINKFILE (N'logical_file_name', 5) -- reducir en 5 MB - Luego corra ALTER DATABASE, con el tamaño que usted quiere que sean. Esto causará que el nuevo tamaño se registre en master.sys.master_files, la cual es un catalogo de sistema que SQL Server usa para recrear una nueva TempDB en blanco cada vez que una server/instance es reiniciada.
USE MASTER
GO
ALTER DATABASE TEMPDB MODIFY FILE (NAME=' logical_file_name, SIZE=6MB)
SELECT DB_NAME(DATABASE_ID)DBNAME, [NAME] LOGICAL_FILENAME, [SIZE]*8/1024 SIZE_MB
FROM MASTER.SYS.MASTER_FILESWHERE DB_NAME(DATABASE_ID) = 'TEMPDB'
Este método elimina el riesgo de errores de consistencia. Con la salvedad, que tendrás que desconectar a todos los usuarios antes de hacer algún cambio. Sin embargo, si lo planeas bien, se podrá hacer esos cambios en 10 minutos haciendo estos pasos:
1. Establezca una Coenxion Dedicada de Administrador (DAC) en el Management Studio para conectarse. Tan sencillo como anteponiendo "Admin:" en frente de la instacia de nombre. P.E., ADMIN:Rep-Server\Instancia1.
2. Corra:
- ALTER DATABASE with the REMOVE -- opción para marcar los .ndf como obsoletos.
- USE MASTER GO ALTER DATABASE TEMPDB REMOVE FILE logical_file_name
- C:\>NET STOP MSSQLSERVER
- o
- NET STOP "SQL Server (MSSQLSERVER)"
- o para la named instance:
- C:\> NET STOP "SQL Server ( instancename )"
- o
- NET STOP MSSQL$instancename
- C:\SQL\MSSQL.1\MSSQL\Binn>sqlservr.exe -c -f
- USE MASTER
- GO
- ALTER DATABASE TEMPDB MODIFY FILE (NAME='logical_file_name', SIZE=6MB)
- C:\NET START MSSQLSERVER
- o
- NET STOP "SQL Server (MSSQLSERVER)"
- ALTER DATABASE TEMPDB ADD FILE (NAME=logical_file_name, FILENAME='C:\bla\bla\Data\logical_file_name.ndf', SIZE=6MB)
- SELECT DB_NAME(DATABASE_ID)DBNAME, [NAME] LOGICAL_FILENAME, [SIZE]*8/1024 SIZE_MB FROM MASTER.SYS.MASTER_FILES WHERE DB_NAME(DATABASE_ID) = 'TEMPDB'
Espero les sirva.
IBM MQSeries con .NET 2008 - I Parte
Introducción
La mensajería por colas de espera se ha usado durante muchos años. Normalmente usado hoy en día para el correo electrónico. Sin utilizar colas, enviar un mensaje electrónico sobre grandes distancias requiere que cada nodo en la ruta esté disponible para remitir dichos mensajes. En un sistema de formación de colas de espera, se guardan los mensajes en nodos intermediarios hasta el sistema está listo para remitirlos o procesarlos. Por supuesto que eso causa cierto grado de overhead en la red, pero pondremos en la balanza ciertos beneficios para justificar este proceder.
Aun así, se procesan billones de transacciones comerciales complejas sin hacer queuing. Si éste es el caso; ¿entonces por qué necesitamos la formación de colas de espera? Piense detenidamente en un sistema que consiste en nodos múltiples dónde estos necesitan comunicarse entre sí. Si un nodo del sistema sufre un problema, muchos otros podrían quedar inutilizables. En un ambiente de queuing, cada programa del juego que constituye el sistema se diseña para desempeñarse como debe ser, como una función autónoma en respuesta a una solicitud específica. Para comunicarse con otro programa, este debe poner un mensaje en una cola predefinida, el otro programa recupera el mensaje de la cola y procesa el mensaje. En pocas palabras queuing es un estilo de comunicación programa-a-programa.
Queuing es el mecanismo por el que se sostienen los mensajes hasta que una aplicación está lista a procesarlos. Este tipo de comunicación permite:
- La comunicación entre programas (puede cada uno está corriendo en los ambientes diferentes) sin tener que escribir el código de comunicación.
- Seleccionar el orden en que un programa procesa los mensajes.
- El balanceo de cargas en un sistema, colocando más de un programa para reparar una cola cuando el número de mensajes excede el umbral permitido.
- Aumentar la disponibilidad de sus aplicaciones, al levantar un sistema alternativo para reparar las colas si su sistema primario está caído.
¿Qué es un mensaje?
En queuing, un mensaje es simplemente una colección de datos enviada por un programa a otro intencionalmente. MQ WebSphere define cuatro tipos de mensaje principalmente:
- Datagrama (Datagram): Un mensaje simple para el que ninguna contestación se espera.
- Solicitud (Request): Un mensaje para el cual se espera una contestación.
- Respuesta (Reply): Una contestación a un mensaje solicitado.
- Reporte (Report): Un mensaje que describe un evento, como la ocurrencia de un error.
Para manipular mensajes se necesita control de la información y de los datos de la aplicación. El control de la información se define en una estructura descriptora de mensajes (MQMD), la cual contiene:
- El tipo de mensaje.
- Un identificador para el mensaje.
- La prioridad para el envío del mensaje.
- La estructura y contenido de los datos de aplicación son definidos por los programas en sí, no por Websphere MQ.
Bueno hasta aquí por hoy.
Bienvenidos
Espero que los posts sean de su agrado.