Te presento mi nuevo sitio web: ---------> "El Futuro de los Datos"

Aunque SQL Server Si!, seguirá activo, iré bajando la frecuencia de publicación.
Si quieres conocer todas las novedades que vaya publicando, te recomiendo que lo visites y te suscribas. Tengo un regalito para mi audiencia:

Tu primer Dashboard en "piloto automático" listo en 30 minutos
Sólo para suscriptores.
.
Mostrando entradas con la etiqueta SQL Server FAQs. Mostrar todas las entradas
Mostrando entradas con la etiqueta SQL Server FAQs. Mostrar todas las entradas

31 ago 2012

Libros migracion SQL Server PDF gratis

La migración a nuevas versiones de SQL Server es un proceso al que tarde o temprano nos tenemos que enfrentar. La tecnología avanza a un ritmo muy rápido.

Ahora dispones de una excelente documentación al respecto, y en español :)

Enrique Catalá, uno de mis compañeros de SolidQ, ha escrito dos ebooks sobre el tema que están disponibles en formato PDF.

La novedad no son estos libros, sino que desde SolidQ hemos decidido compartir nuestros conocimientos y experiencias reflejados en estos y otros libros y ofrecerlos de forma gratuita :)

Libro PDF gratuito: Planificando la migración a SQL Server 2008R2

LibroMigracionSQLServer2008R2

Libro PDF gratis: Planificando la migración de SQL Server 2000-2005 a SQL Server 2008

LibroSQLServer2008Migracion

Espero que os sean de ayuda.

¿Te ha gustado lo que has leido? ¡Compartelo!

24 mar 2011

Instalar y Configurar Integration Services

Mis compañeros de SolidQ, Enrique Catalá y Enrique Puig, han publicado en MSDN, en el Centro de desarrollo de SQL Server, un artículo sobre la instalación y configuración de Integration Services.

Contiene una guía paso a paso mostrando una imagen de cada una de las pantallas, así como recomendaciones de configuración. A ello se agrega un apartado para configurar SSIS en entornos Cluster.

Espero que os resulte interesante y que lo utilicéis para mejorar vuestras instalaciones y configuraciones del producto.

Para acceder al artículo pincha aquí.

30 oct 2010

Características de cada una de las ediciones de SQL Server 2008 R2

Es muy habitual que surjan dudas sobre qué edición de SQL Server debemos adquirir según los requisitos de la empresa. Además ahora en 2008 R2 hay más ediciones: Datacenter, Enterprise, Standard, Workgroup, Web, Express with Advanced Services, Express with tools y Express.

Hay un documento donde se explican con detalle todas las funcionalidades, y sus correspondientes tablas donde se puede ver de una forma muy rápida qué versiones las soportan. Para acceder a él pincha aquí.



19 ago 2009

SQL Server 2008 Express: Limitaciones

Leyendo en los grupos de noticias de SQL Server (microsoft.public.es.sqlserver) he enontrado un hilo simple y muy bien explicado y resumido sobre las limitaciones de SQL Server 2008 Express Edition, con las respuestas de Carlos Sacristán y Emilio Boucau, dos buenos amigos del grupo.

Paso a continuación a comentar dichas limitaciones, basando lo aquí expuesto en esos comentarios:

  • Hasta 16 instancias.
  • Sólo puede utilizar 1GB de RAM por instancia. Aunque el servidor tenga más memoria y ésta pueda ser utilizada por otras aplicaciones, SQL Server sólo utilizará 1GB.
  • Sólo puede utilizar 1 CPU por instancia. En este caso con CPU se refiere a procesador físico (socket), con todos los núcleos (cores) de que disponga, por ejemplo si es un quad-core utilizará ese procesador disponiendo de los 4 núcleos (cores). Aunque el servidor tenga más procesadores físicos no hará uso de ellos.
  • El tamaño máximo por base de datos es de 4GB por base de datos (sólo datos, el log no tiene limitaciones). Deberá tener en cuenta lo siguiente:
    • Son 4GB de datos, es decir entre los ficheros .mdf y ndf que tengamos.
      • Se excluye lo que ocupe el log de transacciones, no importa que tengamos un log de 500GB
      • Se excluye el contenido FILESTREAM (una de las novedades de 2008), es decir puedes tener muchas gigas de fotos, música, documentos, etc. en tu base de datos.
    • Una vez que se llega a este límite se puede seguir trabajando, pero dará error cualquier operación que implique un aumento de ese límite. Por ejemplo se podrán hacer select, delete, incluso update si no necesita ese aumento de tamaño.

Finalmente, para conocer el espacio que ocupan vuestras bases de datos, podéis mirar en los BOL (ayuda de SQL Server):

  • SP_SPACEUSED
  • DBCC SQLPERF(LOGSPACE)

Finalmente os dejo dos links bastante interesantes:

Comparativa entre las diferentes ediciones de SQL Server 2008:
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx

Blog de MSDN sobre SQL Server Express Edition
http://blogs.msdn.com/sqlexpress

Espero que os resulte interesante, y que os ayude a despejar las frecuentes dudas que surgen sobre SQL Server 2008 Express.

20 ene 2009

Mover bases de datos entre servidores SQL Server

Es muy habitual, sobre todo por desconocimiento, que se nos presenten problemas cuando movemos una base de datos de un servidor SQL Server a otro, independientemente del medio que utilicemos (backup, copia de .mdf .ndf .ldf,...). En cada base de datos tenemos información de los usuarios (users) y sus permisos sobre dicha base de datos, esta información, al ir en la propia base de datos, se mueve de un servidor a otro. Pero en la estructura de seguridad de SQL Server, tenemos como primer nivel los logins (que indican quien tiene acceso al servidor) que se almacenan en la base de datos master, y por tanto no se mueven al nuevo servidor. Como mover la base de datos master al nuevo servidor no suele ser la opción apropiada, a parte de por su mayor complejidad, porque posiblemente me lleve otra información que no necesito y además machaque información del servidor destino que necesite, en la KB se ha publicado un artículo detallando todo lo que hay que realizar adicionalmente a mover la base de datos. Aquí os dejo el link:

Cómo mover bases de datos entre equipos que están ejecutando SQL Server

Te recomiendo también que leas el post de Introducción a la Seguridad en SQL Server para aclarar los conceptos básicos de seguridad: logins (inicios de sesión), users (usuarios), roles, etc.

2 ene 2009

Creación de campos Autonuméricos (identity) en SQL Server

Se puede definir una columna de valor incremental al momento de crear su tabla o alterar su estructura.

Adicionalmente, se puede definir una "semilla" que se utilizara como valor inicial, en la primera fila, mientras que se utilizara el valor "incremento" para ir calculando los siguientes.

Para realizar esta tarea desde el Administrador Corporativo, bien en la creación o en la modificación de una tabla, tenemos los campos: identidad (identity), iniciación de identidad, e incremento de identidad.

Podemos utilizar cualquier tipo de dato numérico, en la figura anterior hemos utilizado un int, cuyo valor inicial es 100, y su incremento 1.

En el siguiente ejemplo, crea la misma tabla "alumnos" con un campo que representa
un código de identificación que tendrá valores a partir de 100:

CREATE TABLE alumnos (Nombre char(20), ident int IDENTITY (100,1), curso char(5), edad int null)

En el siguiente ejemplo, se altera una tabla para agregar una columna autoincremental:
ALTER TABLE ex_alumnos ADD ex_alumno_Id INT IDENTITY (100,1)

Usar NOT FOR REPLICATION.

La opción NOT FOR REPLICATION se utiliza en la duplicación de Microsoft® SQL Server™ 2000 para implementar intervalos de valores de identidad en un entorno con particiones. La opción NOT FOR REPLICATION es especialmente útil en una duplicación transaccional o de mezcla cuando una tabla publicada se divide en particiones con filas de varios sitios.

Cuando un agente de duplicación se conecta con una tabla con cualquier identificador de inicio de sesión, se activan todas las opciones NOT FOR REPLICATION de la tabla. Cuando se establece la opción, SQL Server 2000 mantiene los valores de identidad originales de las filas agregadas por el agente de duplicación, pero sigue incrementando el valor de identidad en las filas agregadas por otros usuarios. Cuando un usuario agrega una nueva fila a la tabla, el valor de identidad se incrementa de forma normal. Cuando un agente de duplicación duplica dicha fila en un suscriptor, el valor de identidad no se ve modificado cuando la fila se inserta en la tabla del suscriptor.

Por ejemplo, considere una tabla que contenga filas insertadas desde dos orígenes: el Publicador A y el Publicador B. Las filas insertadas en el Publicador A se identifican con valores crecientes entre 1 y 1000, y las filas del Publicador B se identifican con valores entre 1001 y 2000. Si un proceso del Publicador A inserta una fila localmente en la tabla, SQL Server asigna a la primera fila el valor 1, a la siguiente fila el valor 2 y así sucesivamente, en incrementos automáticos. De forma similar, si un proceso del Publicador B inserta una fila localmente en la tabla, a la primera fila se le asigna el valor 1001, a la siguiente fila el valor 1002, y así sucesivamente. Cuando se duplican las filas del Publicador A en el B, los valores de identidad siguen siendo 1, 2, etc., pero los valores de inicio locales no se reinician en el Publicador B.

Independientemente del papel que desempeñe en la duplicación, la propiedad IDENTITY no requiere que sea única por sí misma, simplemente inserta el valor siguiente. Aunque puede proporcionar un valor explícito con SET IDENTITY INSERT, dicha función no es apropiada para la duplicación, ya que también vuelve a iniciar el valor. La opción NOT FOR REPLICATION se ha creado específicamente para las aplicaciones que utilizan la duplicación. Por ejemplo, sin esta opción, en cuanto la primera fila del Publicador B (con valor 1001) se propagara al Publicador A, el siguiente valor de identidad del Publicador A sería 1002. La opción NOT FOR REPLICATION es una forma de indicar a SQL Server 2000 que el proceso de duplicación prescinde de dicho valor cuando suministra uno explícito y que el contador local no tiene que reiniciarse. Cada publicador que utilice esta opción obtiene el mismo permiso para no reiniciar el contador.

Se requieren procedimientos almacenados personalizados que utilicen instrucciones INSERT, UPDATE y DELETE con listas de columnas completas, antes de que la duplicación funcione con propiedades de identidad. Si no se utilizan listas de columnas completas, se devolverá un error.

El siguiente ejemplo de código ilustra cómo implementar identidades con intervalos diferentes en cada publicador:

En el Publicador A, empieza por 1 e incrementa de 1 en 1.
CREATE TABLE authors ( COL1 INT IDENTITY (1, 1) NOT FOR REPLICATION PRIMARY KEY )

En el Publicador B, empieza por 1001 y se incrementa de 1 en 1.
CREATE TABLE authors ( COL1 INT IDENTITY (1001, 1) NOT FOR REPLICATION PRIMARY KEY )

Después de activar la opción NOT FOR REPLICATION, las conexiones de los agentes de duplicación con el Publicador A insertan filas con valores como 1, 2, 3 y 4. Dichas filas se duplican en el Publicador B sin ser modificadas (es decir, 1, 2, 3 y 4). Las conexiones desde agentes de duplicación con el Publicador B obtienen los valores 1001, 1002, 1003 y 1004. Dichas filas se duplican en el Publicador A sin ser modificadas. Cuando se distribuyen o se mezclan todos los datos, ambos Publicadores tienen los valores 1, 2, 3, 4, 1001, 1002, 1003 y 1004. El valor de la siguiente fila insertada localmente en el Publicador A es 5. El valor de la siguiente fila insertada localmente en el Publicador B es 1005.

Se recomienda utilizar siempre la opción NOT FOR REPLICATION con la restricción CHECK para asegurar que los valores de identidad asignados están dentro del intervalo permitido. Por ejemplo:
CREATE TABLE sales
(sale_id INT IDENTITY(100001,1)
NOT FOR REPLICATION
CHECK NOT FOR REPLICATION (sale_id <= 200000),
sales_region CHAR(2),
CONSTRAINT id_pk PRIMARY KEY (sale_id)
)

Incluso si alguien utiliza SET IDENTITY INSERT, todos los valores insertados localmente quedan dentro del intervalo definido. Sin embargo, los procesos de duplicación siguen quedando fuera de la comprobación.

Nota Si va a utilizar la duplicación transaccional con la opción de actualización de suscriptores inmediata, no utilice el diseño IDENTITY NOT FOR REPLICATION. En su lugar, cree la propiedad IDENTITY sólo en el publicador y haga que el suscriptor utilice sólo el tipo de datos de base (por ejemplo, int). Así, el siguiente valor de identidad siempre se genera en el publicador.

Usar DBCC CHECKIDENT.

Se utiliza para cambiar o alterar el contenido de una columna auto incremental (IDENTITY).

Sintaxis
DBCC CHECKIDENT ( 'table_name' [ ,
{ NORESEED | { RESEED [ , ew_reseed_value ] } } ] )

En este ejemplo se establece el valor de identidad actual de la tabla jobs en 30.

USE pubs
GO
DBCC CHECKIDENT (jobs, RESEED, 30)
GO

30 dic 2008

Tratamiento de fechas y horas en SQL Server

Introducción.

El tratamiento de fechas en SQL Server es uno de temas que más preguntas generan en los foros y grupos de noticias. SQL Server tiene los tipos de datos datetime y smalldatetime para almacenar datos de fecha y hora.

No hay tipos de datos diferentes de hora y fecha para almacenar sólo horas o sólo fechas. Si sólo se especifica una hora cuando se establece un valor datetime o smalldatetime, el valor predeterminado de la fecha es el 1 de enero de 1900. Si sólo se especifica una fecha, la hora será, de forma predeterminada, 12:00 a.m. (medianoche), es decir, las 00:00.

Nota Importante: En SQL Server 2008 sí que tenemos como novedad tipos de datos para almacenar sólo la fecha y sólo la hora. Por tanto todo lo que contamos a continuación se puede solucionar usando los nuevos tipos de datos.


Tipo de datos Datetime.

Datos de fecha y hora comprendidos entre el 1 de enero de 1753 y el 31 de diciembre de 9999, con una precisión de un trescientosavo de segundo, o 3,33 milisegundos.

SQL Server rechaza todos los valores que no puede reconocer como fechas entre 1753 y 9999.


Tipo de datos Smalldatetime.

Datos de fecha y hora desde el 1 de enero de 1900 al 6 de junio de 2079, con precisión de minutos. Entonces si se utiliza un valor smalldatetime los segundos y milisegundos son siempre 0.

Diferencia entre Datetime y Smalldatetime.

SQL Server almacena internamente los valores de tipo de datos datetime como enteros de 4 bytes y los valores smalldatetime como enteros de 2 bytes.


Funciones de fecha y hora (Transact-SQL)

Estas funciones escalares realizan una operación sobre un valor de fecha y hora de entrada, y devuelven un valor de cadena, numérico o de fecha y hora:

DATEADD
DATEDIFF
DATENAME
DATEPART
GETDATE
DAY
MONTH
YEAR


Trabajando con fechas ...

Con algunos pequeños ejemplos trataremos de resolver los mayores problemas para trabajar con estos tipos de datos. Para ello utilizaremos las funciones CAST y CONVERT.

Separando Fecha y Hora.

Declare @Fecha datetime
Set @Fecha = Getdate()
Select Convert(Char(10), @Fecha,112) As SoloFecha, Convert(Char(8), @Fecha, 108) As SoloHora
SoloFecha SoloHora
---------- --------
20010803 07:35:02
(1 row(s) affected)

Otra forma de conseguir el mismo resultado:

Declare @Fecha datetime
Set @Fecha = Getdate()
SELECT Convert(varchar, @Fecha, 3) AS SoloFecha, Convert(varchar, @Fecha, 8)

Operaciones con Fechas (diferencia entre dos fechas).

Obtener diferencia de meses, dias, minutos, etc. entre dos fechas.

Para realizar operaciones entre dos fechas MSSQL tiene la función DATEDIFF. Veamos algunos ejemplos de cómo utilizarla:

declare @FechaIngreso datetime
declare @FechaEgreso datetime

select @FechaIngreso = '19981231 15:15'
select @FechaEgreso = '20021005 10:10'

Select
DATEDIFF(dd, @FechaIngreso, @FechaEgreso) AS Dias,
DATEDIFF(mm, @FechaIngreso, @FechaEgreso) AS Meses,
DATEDIFF(mi, @FechaIngreso, @FechaEgreso) AS Minutos

Para obtener otras diferencias podemos recurrir a la siguiente tabla:

Parte de la fecha Abreviaturas
año aa, aaaa
trimestre tt, t
mes mm, m
día del año da, a
día dd, d
semana sm, ss
hora hh
minuto mi, n
segundo ss, s
milisegundo Ms

Otro ejemplo de DATEDIFF en donde recuperados los datos de la ultima semana partiendo de la fecha del día:

SELECT TusDatos
FROM TuTabla
WHERE
DATEDIFF(dd, TuFecha, GetDate()) <= 7

Continuando con las operaciones con las fechas, veamos como podemos hacer para sumar, restar, días, minutos, meses, a una fecha, para ello utilizamos la función DATEADD:

select convert(varchar(12), DATEADD(month, -1, getdate()), 106)
as 'un mes atrás'
select convert(varchar(12), DATEADD (week, -1, getdate()), 106)
as 'una semana atrás'
select convert(varchar(12), DATEADD (day, -1, getdate()), 106) as 'ayer'

Sugerencia:

Estos ejemplos que mostramos a continuación devolverían el mismo resultados que las consultas anteriores, pero, si, siempre hay un pero.... hace un tiempo nuestro compañero Fernando Guerrero me sugirió no utilizarlo pues este truco no está soportado oficialmente por SQL Server ni por el estándar ANSI.

select convert(varchar(12), getdate()-7), 106) as 'una semana atrás'
select convert(varchar(12), getdate()-1), 106) as 'Ayer'

Funciona, pero no sabemos hasta cuando.


Ampliar información:

Puede consultar en los B.O.L. (Books OnLine - Libros en Pantalla) cualquiera de las instrucciones citadas anteriormente.

También puede consultar los artículos y ejemplos publicados en http://www.portalsql.com
Allí busque la palabra 'fechas' y obtendrá todos los artículos publicados sobre el tema.

22 dic 2008

Cómo Reducir Log de Transacciones de SQL Server

Soluciones rápidas al problema.

Hacer Backup del Log de Transacciones ( Transaction Log ) y reducir el fichero.

  1. Ejecuta dos o tres veces la instrucción CHECKPOINT. Esto asegurará que todas las páginas de memoria se han escrito en el fichero de datos.
  2. Luego haz un BACKUP LOG WITH TRUNCATE_ONLY para que trunque el registro de transacciones.
  3. Posteriormente ejecutas DBCC SHRINKFILE indicando el nombre del fichero del log a reducir.

    (En la ayuda puedes ampliar información sobre estos dos mandatos).

Eliminar el fichero para que se genere de Nuevo (Esta solución es demasiado drástica, emplearla solo si falla la anterior):

  1. Pon la base de datos en modo "single user".
  2. Ejecuta CHECKPOINT dos o tres veces. Esto asegurará que todas las páginas de memoria se han escrito en el fichero de datos.
  3. Asegúrate de que no hay conexiones abiertas a la base de datos, con lo que no puede haber transacciones a medio ejecutar.
  4. Utiliza sp_detach_db para desconectar dicha base de datos.
  5. Elimina el fichero de log.
  6. Utiliza sp_attach_db para reconectar la base de datos. SQL Server creará un nuevo fichero de log.

    ¡¡¡ IMPORTANTE !!!
    Si no ejecutas el proceso completamente y en este orden, podrías tener problemas de consistencia de información en el fichero de datos.
    Por ejemplo, si apagas el equipo sin más, SQL Server no ha tenido tiempo de volcar las páginas de datos de la memoria al disco. Al reiniciar SQL Server, el problema será corregido utilizando la información contenida en el registro de transacciones, pero si este no está presente, el archivo de datos se dará por bueno, y podría ser realmente inconsistente.

    Otro detalle importante a tener en cuenta es que el log no se limpia nunca completamente, ya que siempre hay operaciones internas que SQL Server necesita mantener en él.

 

Causas habituales del crecimiento del Log de Transacciones ( Transaction Log ).

Si el log ha crecido mucho es porque SQL Server lo ha necesitado. Esto es debido a una de las siguientes causas:

  • Eso es lo que normalmente sucede y se debería ajustar la estrategia de backup para hacer copias del log más a menudo.
  • Si el crecimiento del log se debe a una ejecución (insert, update, delete) que afecta a un gran número de registros, bien por haber lanzado un proceso de actualización masiva o porque alguien ha ejecutado una consulta mal formada, que habría que detectarla (y darle un tirón de orejas al que la haya enviado).

Las copias completas de la base de datos no truncan el registro de transacciones. Utiliza una estrategia de copia de seguridad que mezcle copias completas de la base de datos con copias del registro de transacciones.

Puedes detectar las consultas enviadas a SQL Server con el Profiler.

No debes borrar el registro de transacciones manualmente salvo causa de fuerza mayor. Lo que debes hacer es diseñar una estrategia de copia de seguridad que sea acorde con el volumen de transacciones que tiene tu sistema.

 

Problemas habituales que impiden reducir el tamaño del Log de Transacciones ( Transaction Log ).

Los pasos para truncar el Transaction log pueden no ser tan obvios como pueda parecer:

El registro de transacciones está compuesto por al menos dos registros virtuales (VLF = Virtual Log Files). El truncado del registro de transacciones se realiza VLF a VLF. Si sólo tienes dos registros virtuales y te ocupan todo el fichero no podrás truncarlo, aunque dudo que cada VLF llegue a ocupar mucho espacio. (Para ampliar información sobre este punto, consulta en la ayuda 'Trucar el Registro de transacciones', encontrarás información detallada y un gráfico muy explicativo).

Al ejecutar una instrucción DBCC SHRINKFILE solo se le indica a SQL Server que se quiere reducir el tamaño físico del fichero de LOG. Si el último VLF está al final del log, aunque el resto del fichero esté vacío, no se podrá truncar el fichero, ya que SQL Server sólo puede reducirlo recortando por el final.

Supongamos que hay una estrategia de copia de seguridad que incluye copias completas y copias del log. En este caso son las copias del log las únicas que truncan el registro de transacciones, por lo que si se ha ejecutado o no DBCC SHRINKFILE, el registro no se truncará lógicamente hasta que se haga una copia de seguridad del log (o se ejecute BACKUP LOG TuBase WITH TRUNCATE_ONLY).

Sin embargo si el último VLF no está completo, no se podrá truncar, por lo que se tendrá que forzar su llenado. Al ejecutar DBCC LOGINFO(TuBase) se obtendrá una lista de VLF, si te fijas en la columna Status, 2 significa que no está activo o que al menos no es reutilizable. Envía alguna actualizaciones nulas (UPDATE TuTabla SET Campo1 = Campo1, por ejemplo) y vuelve a ejecutar el comando DBCC LOGINFO hasta que veas que hay algún otro VLF con status 2.

Ahora si que se puede ejecutar el BACKUP LOG para truncar el LOG y tras esto SQL
Server podrá recortar el fichero físicamente eliminando uno o más VLFs.

 

Enlaces con información de Microsoft sobre el tema.

INF: Cómo reducir el registro de transacciones de SQL Server

A consultar en los Books On Line y ampliar información:

DBCC SHRINKFILE
DBCC SHRINKDATABASE
DBCC LOGINFO
BACKUP LOG
sp_attach_db
sp_detach_db

Google