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.

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.

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)

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.

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.

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.