Nuevo libro de SQL Server 2014 en Español

By Juan Carlos Heredia Mayer 06/08/2014 Base de Datos

Microsoft SQL Server 2014 en EspañolEn este blog siempre he estado recomendado materiales y recursos distribuidos en la red sobre SQL Server y otros temas similares. Esta vez me complace presentar mi propio libro de Programación y Administración de Base de Datos en Microsoft SQL Server 2014, publicado en formato electrónico a través de Amazon y Google Play.

Es la primera vez que publico un libro en formato electrónico. Anteriormente he tenido la oportunidad de publicar otros títulos en formato impreso, pero esta vez me decidí por este formato ya que no solo es la tendencia sino por su practicidad en la distribución, no solo en el mercado local sino en todo el mundo (para gente de habla hispana, claro está) . Me hace mucha ilusión compartir con la juventud estudiosa y profesional, conocimientos sobre SQL Server que he ido alimentando a través de todos estos años usando este producto.

La presente publicación brinda las técnicas y estrategias básicas y avanzadas para una buena programación y administración de base de datos usando Microsoft® SQL Server™. Si bien, hace una referencia a la versión 2014 recientemente lanzada por Microsoft, todo el contenido del libro podrá ser usado también en versiones anteriores del programa. Así que no hace falta preocuparse en conseguir esta versión específicamente. Incluso la edición Express (totalmente gratuita) valdrá perfectamente para seguir las lecciones.

Durante la lectura, encontrarás que después de cada presentación de un concepto (teórico) inmediatamente verás uno o más ejemplos de tal concepto. Es por eso que la presente publicación se caracteriza por ser un texto netamente práctico, que actúa como una guía que imaginariamente ve más allá de sus necesidades y le da un panorama más amplio con nuevas formas o métodos de usar los conceptos que poco a poco usted va asimilando. Según mi opinión, considero que la mejor manera de enseñar programación es mediante ejemplos, ya que la descripción de los comandos, la sintaxis y las referencias del lenguaje no son suficientes para que una persona aprenda a programar.

Los temas tratados en esta publicación son:

  • Teoría de Base de Datos
  • Planificación de la Seguridad
  • Administración de SQL Server
  • Transact-SQL
  • Trabajando con Tablas y Vistas
  • Consultas y Modificación de Datos
  • Consultas con múltiples tablas: JOINs
  • Optimizando el acceso a los datos mediante índices
  • Integridad de los Datos
  • Implementación de la lógica de negocios: Procedimientos almacenados
  • Implementación de Desencadenadores
  • Ampliando la lógica de negocios: Funciones definidas por el usuario
  • Proceso Orientado a Registros: Usando Cursores
  • Administración de Transacciones y Bloqueos

Si te interesa, échale un vistazo (en ambas plataformas se puede obtener una vista previa gratuita) y si te gusta te animo a comprarlo. Estoy seguro que te servirá y te ayudará en tu día a día en la administración y programación de SQL Server ™.

Comprar en Amazon
SQL Server 2014 | Amazon Kindle
Comprar en Google Play
SQL Server 2014 | Google Play Books

 

 

T-SQL: Borrar el registro de transacciones

By Juan Carlos Heredia Mayer 04/07/2014 Base de Datos

SQL SERVER Hay determinados momentos en que nos encontramos un error como el siguiente:

Msg 9002, Level 17, State 4, Line 1
The transaction log for database ‘MIBASEDEDATOS’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Este error, nos indica que tenemos lleno el registro de transacciones de la base de datos (Transaction Log).

El procedimiento ‘normal’ para borrar el registro de transacciones, es:

BACKUP LOG [MIBASEDEDATOS] WITH TRUNCATE_ONLY 
DBCC SHRINKFILE(NOMBRE_LOGICO_LOG, 1)

Sin embargo aún así, hay casos en el que seguimos obteniendo el error. Para esto deberemos optar por una solución más drástica, como borrar físicamente el fichero LOG en el disco. Para ello, lo primero que tenemos que hacer es  “Separarar”  (Detach) la base de datos con el siguiente procedimiento:

  1. Forzamos la escritura de las páginas en memoria con CHECKPOINT (repetimos varias veces este comando).
  2. Separamos la base de datos con sp_detach_db

    USE [master] 
    GO 
    EXEC master.dbo.sp_detach_db @dbname = N’MIBASEDEDATOS’ 
    GO
  3. Borramos el fichero .LDF físico existente en nuestro disco duro. Normalmente, su ubicación es: C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data\MIBASEDEDATOS.LDF. Cuidado con borrar el fichero MDF (este fichero es de la base de datos).
  4. Una vez eliminado el fichero .LDF, procedemos a "Adjuntar" (Atach) la base de datos, sin indicarle el fichero LDF. De esta forma, SQL Server automáticamente genera un nuevo fichero LDF de transacciones

    USE [master] 
    GO 
    CREATE DATABASE [MIBASEDEDATOS] ON
        (FILENAME = N’C:\Archivos de programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data\MIBASEDEDATOS.MDF’)
    FOR ATTACH
    GO

Espero que os sea de utilidad.

Clustered y Non Clustered Index en SQL Server

By Juan Carlos Heredia Mayer 03/06/2014 Base de Datos

Una pregunta muy común en el mundo de SQL Server, es cuál es la diferencia entre un índice clustered y un índice non-clustered (índices agrupados y no agrupados) y en qué caso conviene usar un índice u otro. Empecemos a describir las características generales de un índice y luego de estos tipos de índices y las conclusiones van a ser evidentes. Aunque aquí tenemos la información oficial http://msdn.microsoft.com/es-es/library/ms190457.aspx, a continuación veremos una breve explicación.

Los índices son objetos de la bases de datos, cuya función es optimizar el acceso a datos. A medida que las tablas se van haciendo más grandes y se desea hacer consultar sobre estas tablas, los índices son indispensables. Algo así como el índice de un libro,  cuando lo tenemos a mano y queremos buscar un tema,  no se nos ocurre buscar página a página hasta encontrar el tema buscado, sino que lo más común es buscar el tema en el libro y luego vamos directamente a la página indicada.


Estructura interna de un índice:

En SQL Server (internamente), un índice normal es una estructura de árbol, que cuenta con una página principal y luego esta con paginas hijas, que a su vez tiene más paginas hijas hasta llegar a la pagina final del índice (leaf level). La clave del índice está repartida en las páginas del índice, de modo tal que la búsqueda se haga leyendo la menor cantidad posible de datos.

SQL Server Tree Leaf

SQL Server Tree Leaf

Después de esta brevísima introducción, donde está la diferencia entre un índice clustered y uno non-clustered? En la la ultima pagina del índice (leaf level). En un índice non-clustered, la clave por la que buscamos tiene un puntero a la página de datos donde se encuentra el registro. Mientras que en índice clustered, la última página es la página de datos!. Con lo cual, SQL Server, se ahorra hacer un salto para leer los datos del registro (Bookmark lookup). La diferencia es importante, ya que el uso de este tipo de índices al evitar tener que hacer lecturas adicionales para traer el registro, por lo tanto tienen más rendimiento.

Búsqueda por clustered index:

clustered index

Búsqueda por non-clustered index:

non-clustered index

Desde SQL Server 2005 existe una nueva interesante característica en los índices non-clustered. Ahora es posible incluir dentro del  nivel de página del índice, campos que en sí, no son parte de la clave. Esto nos permitirá en algunos casos, evitar el salto a la página de datos (Bookmark Lookup) que habíamos hablado anteriormente. Aunque hay que tener cuidado de seleccionar bien que campos se desean incluir al índice, porque al poner demasiados campos se expandiría mucho el índice, haciendo ineficiente. Por ejemplo, si tenemos una tabla Personas cuyo campo DNI es un índice non-clustered y queremos hacer una consulta que solo traiga el Apellido y DNI, entonces si incluimos el campo Apellido, nos ahorraríamos tener que ir a la página de datos para buscar el valor. Es importante recalcar que el campo Apellido no sería parte de la tabla, sino un campo mas en la pagina final del índice.

Ahora bien, entonces porque no siempre usar índices clustered? Bueno, en primer lugar, lamentablemente solo puede haber un solo índice clustered por tabla. La razón es muy sencilla y lógica: Los registros de la tabla físicamente son las paginas leaf-level del índice clustered. Los datos de la tabla esta ordenados según el índice. Y obviamente una tabla no puede simultáneamente estar físicamente ordenada de 2 maneras diferentes.
Por lo tanto, en tablas grandes y muy consultadas, tenemos que ser cuidadosos y analizar a que campos vamos a seleccionar para ser llaves del índice clustered. Tenemos  un solo índice de este tipo por tabla, ¡¡¡no hay que desperdiciarlo!!!

Este último punto es importante para saber en qué situaciones y para que campos se debe utilizar un clustered index o un non-clustered.

Clustered & Non Clustered Index