martes, 1 de septiembre de 2009

Cambiar el idioma por omisión de tu motor SQL Server

Mira puedes ejecutar los siguientes comandos:

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

Hola amigos, aquí les dejo una instrucción para esa gran pregunta: "Puedo porner en cero de nuevo un campo identity una vez usado?", respuesta: sí.

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

Les comento esta nueva opción de obtener la mejor información acerca de temas de infraestructura, desarrollo, BI, etc.


En las imágenes están los links, espero les sirva.

lunes, 15 de junio de 2009

SQL Server Tips 002: Consultas ad-hoc como cadenas.

Si necesitas crear un snippet en Transac SQL que por las circunstancias debes armar dentro de un VARCHAR, revisa este código. NOTA: pon atención a las comillas simples triples.

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

Un buen amigo me ha pasado este link del Microsoft TechNet subido el 17/02/2005 por un grupo de especialistas en la materia, esta muy completo, sobretodo la sección de la Implementación de la ventana deslizante.

Revísenlo vale la pena.

miércoles, 27 de mayo de 2009

Modelo de encripción de datos: SQL Server 2008 II Parte

Uno de los problemas más grandes de una organización, es la seguridad de su información. Dentro de este tópico están los respaldos de una BD, los cuales son propensos a robo, obien, ser recuperados casi en cualquier instancia de SQL Server.

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.

Esta característica implementa la encripción a nivel de base de datos complementada con la encripción a nivel de filas, que ya existía en la versión anterior de SQL Server. Esto proteje basicamente de accesos a la base de datos en forma directa o por restauración de un backup en otra instancia de SQL Server.

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:

Por omisión, los respaldos no son encriptados, veámos un ejemplo:

BACKUP DATABASE AdventureWorks TO DISK = 'C:\AdventureBCK.bak' WITH INIT, STATS = 10

Luego de realizar el anterior comando, podemos comprobar la no encriptación consultando directamente el archivo .bak.

Nótese que la información es altamente legible (texto Unicode), lo único de cuidado es que las palabras están separadas ellas mismas y entre si por espacios en blanco.

Ya captaron el gran problema? Pero para dicha nuestra, SQL Server 2008 ya nos permite salvaguardar como se debe nuestros datos. Analicemoslo a continuación en forma resumida.

Para habilitar la encriptación primero debemos setear el servidor. Para hacer eso, creemos una llave maestra de base de datos en la BD Master.

USE master GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'cLAvE&&ACC350'

Luego, se debe crear el certificado server-based que será usado para encriptar la BD.

CREATE CERTIFICATE AdventureCert WITH SUBJECT = 'El Super Certificado de mi BD'

El paso siguiente es configurar la encripción en sí para la BD creándo la llave de encripción y la clave usando el certificado recién creado en el paso previo.

USE AdventureWorks
GO
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE AdventureCert
GO

El algoritmo de encripción que elijan es completamente a gusto de ustedes. Para seleccionar dicho algoritmo en SQL Server, revisen el artículo que les coloque en el post anterior. Continuando entonces, debemos habilitar la encripción a nivel de base de datos.

ALTER DATABASE AdventureWorks SET ENCRYPTION ON

Y como último paso volvemos a encriptar la BD, pero con un nombre distinto.

BACKUP DATABASE AdventureWorks TO DISK = 'C:\AdventureBCKEncrip.bak' WITH INIT, STATS = 10

OK listo! Ahora les toca a ustedes consultar de nuevo el archivo .bak, para darse cuenta que ya el nombre buscado al principio no aparece. Pronto les mostraré como recuperar el respaldo encriptado en una instancia de SQL Serve diferente. Nos vemos.

Modelo de encripción de datos: SQL Server 2008


Me encontré en internet este link de technet que indica el modelo a seguir para la encripción de datos, revísenlo.

martes, 26 de mayo de 2009

Temporary tables vs table variables


Se parecen verdad? Pero sólo en los nombres, porque estos términos distan hasta en cosas como el rendimiento, veámos.

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:


  1. 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.

  2. 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.

  3. Las tablas temporales debido a que usan estadísticas, generan recompilaciones, cosa que no pasa con las variables table.

  4. 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.

  5. 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

Descriptor de mensajes

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.
La estructura y contenido de los datos de aplicación son determinados por los aplicativos participantes, no por WebSphere.

¿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

Debido a situaciones de origen laboral, en la oficina se ha tenido que contar muchas veces con la opción de comprimir la base de datos temporales de sistema que tiene SQL Server (2005-2008).

Encontre dos maneras (lo que indica que no existan más formas) de realizar esa tarea, los describo de seguido.

Método 01: Comprimir y modificar archivo


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:
  1. 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
  2. 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)
Note que hasta que SQL Server es reiniciado (cuando TempDB es recreada) los cambios no mostraran los nuevos valores en la Database Properties o en la Shrink File GUI. Sin embargo, se pueden verificar los cambios inmediatamente con:

SELECT DB_NAME(DATABASE_ID)DBNAME, [NAME] LOGICAL_FILENAME, [SIZE]*8/1024 SIZE_MB
FROM MASTER.SYS.MASTER_FILESWHERE DB_NAME(DATABASE_ID) = 'TEMPDB'


Método 02: Modificar archivos en modo de usuario restringido


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
3. Detenga la instancia desde el command prompt. Para la default instance use:
  • 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
4. Inicie la instancia en modo restringido con:
  • C:\SQL\MSSQL.1\MSSQL\Binn>sqlservr.exe -c -f
5. Mofique la TempDB con el nuevo tamaño inicial para el .mdf y el .ldf desde la conexión dedicada en SSMS (hasta que reinicie SQL Server en modo normal, será la única conexión disponible).
  • USE MASTER
  • GO
  • ALTER DATABASE TEMPDB MODIFY FILE (NAME='logical_file_name', SIZE=6MB)
6. Regrese al command prompt y teclee Ctrl + C para salir del modo restringido (diga si cuando el prompt pregunte si quiere detener SQL Server). Entonces inicie la instacia en modo normal. Para la default instance:
  • C:\NET START MSSQLSERVER
  • o
  • NET STOP "SQL Server (MSSQLSERVER)"
7. Modifique la TempDB con la opción Add File activada con el nuevo tamaño para los archivos .ndf.
  • ALTER DATABASE TEMPDB ADD FILE (NAME=logical_file_name, FILENAME='C:\bla\bla\Data\logical_file_name.ndf', SIZE=6MB)
8. Al final corra esta consulta para asegurarse de que todos los cambios fueron realizados apropiadamente en la base de datos Master:
  • 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'
Podemos observar que el primer método es más simple y rápido, pero pero se corre un riesgo inherente de corromper los datos en la TempDB. Además, la operación de compresión puede no terminar debido al uso concurrente de dichos archivos. Ahora bien, el segundo método es más elaborado pero asegura una operación limpia. Sin embargio requiere detener el sistema.
Espero les sirva.

IBM MQSeries con .NET 2008 - I Parte

Esta es la primera entrega de una serie de artículos sobre el uso de MQ's en .NET, utilizando VB .NET 2008. Esta serie de artículos es dirigido a arquitectos y desarrolladores que están buscando una manera de integrar las aplicaciones de .NET con servidores IBM WebSphere MQ (IBM MQSeries).

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

Este es mi primer post de introducción. Espero que de ahora en adelante podamos compartir conocimientos de diferentes áreas de desarrollo de software, arquitectura, bases de datos y más.

Espero que los posts sean de su agrado.