capítulo 1 - diseño de base de datos

Diseño y Arquitectura de Base de Datos

Al finalizar el capítulo, el alumno podrá:

Reconocer los distintos formatos de disco.

Definir la mejor arquitectura para crear una base de datos.

Elegir el mejor arreglo de disco para el propósito de su base de datos.

Aplicar la mejor distribución de sus objetos de base de datos.

Temas: 1. Formateo y alineamiento de Disco 2. Arreglo de Disco 3. Diseño de la Base de datos TEMPDB 4. Diseño de Base de datos

Mejores prácticas con Transac SQL 2008 2

CIBERTEC

1. Formateo y alineamiento de Disco

Muchas veces cuando se quiere mejorar los tiempos de I/O (entradas y salidas de disco) los factores a tomar en cuenta son: velocidad y tamaño de disco, siempre que los discos sean dedicados, compartidos, virtuales o el tipo de RAID.

El contar con particiones alineadas, justifica en un 30% aproximadamente, del rendimiento de nuestros sistemas.

1.1 Alineamiento de Disco

La página es la unidad básica del almacenamiento de datos en SQL Server. El espacio en disco asignado a un archivo de datos (.mdf o .ndf) de una base de datos, se divide lógicamente en páginas numeradas de forma contigua de 0 a n. Las operaciones de E/S de disco se realizan a nivel de página; es decir, SQL Server, lee o escribe páginas de datos enteras. El tamaño de página es de 8 KB, esto significa que las bases de datos de SQL Server tienen 128 páginas por megabyte.

Asimismo, existen 3 datos importantes para alinear las particiones:

Partition Offset: es el tamaño de primer sector y a partir de éste, empiezan las particiones, lo cual garantiza la omisión de asignación de páginas en este sector (creado por el hadware de almacenamiento). El Partition Offset alberga MBR (Master Boot Record) de 512KB, Tabla de partiones, la firma del disco y los códigos de máquina que se encargan de recibir el control de la BIOS.

La primera partion no empieza después de esta partición, sino que se reserva un número de sectores, como en los sistemas operativos Windows, que reporta un número de sectores ocultos (63 sectores)

Stripe Unit Size: las controladoras de disco definen un tamaño mínimo para cada una de las bandas que se utilizarán para almacenar datos y paridades en los sistemas de RAID, esto es en los sistemas en los que los volúmenes comprende más de un disco físico. Estas bandas comprenden un cierto número de sectores de


CIBERTEC

disco y su tamaño será múltiplo de la cantidad de sectores de disco. En los sistemas operativos Windows, el Windows Volume Maneger, define un valor de 64k para el Stripe Unit Size.

Allocation Unit: es el menor tamaño posible que puede ocupar un fichero. Su valor se puede especificar, explícitamente, a la hora de formatear. En NTFS es de 4K y toma un valor máximo de 64K.

Ahora, el alineamiento de las particiones se base en buscar una buena relación entre estos tres datos, de manera que las operaciones de lectura/escritura no busquen la data en más de un disco que conformen el volumen. Esto lleva a que al momento de leer o escribir se deba hacer en diferentes discos y la acumulación de esto, hace que se pierda performance. Para evitar esto, las siguientes relaciones, se debe entregar un número entero.

Patition Offset / Stripe Size Unit

Stripe Size Unit / Allocation Unit

Ejemplo 1

Suponiendo que el servidor de producción tiene problemas de performance, lo primero a realizarse es verificar el tamaño del Partition Offset; luego, se ingresará al Menú Inicio\Ejecutar y escribir Cmd.

Seguidamente, se escribirá C:\\Windows\\System32-

Estando es esta carpeta, se deberá escribir: wmicpartition get BlockSize, StartingOffset, Name, Index.

Esto devolverá el tamaño del StartingOffSet

Ahora, para hacerlo más simple, se dividirá el valor del StartingOffSet entre 1024 y si el valor devuelto es entero, entonces se indicará que la partición está alineada.

Si el valor devuelto no fuera entero, entonces se ingresará por el Menú Inicio\Ejecutar y se escribirá Cmd. Luego, regedit.

Ahora, se ubicará en la carpeta

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vds\Alignment


CIBERTEC

Todas las variables deberán ser alineadas a 1024Mb o (1048576 bytes)

1.2 Formatear un Disco

Formatear un disco significa borrar todo lo que contiene y esto se puede hacer en dos formatos NTS y FAT32. Los formatos significan la forma en que los discos guardarán

información.

El formato NTFS se puede utilizar a partir de Windows 2000 en adelante, mientras que FAT32 no permite tener archivos mayores a 4GB.

El formato del disco permite definir el tamaño lógico del sector o bloque y esto es independiente del tamaño de la partición. Los formatos NTFS permiten utilizar tamaño, que va desde los 512 bytes hasta los 64K.

Cuando se desea formatear un disco, solo se hace clic derecho sobre la unidad a formatear.


CIBERTEC

Luego, se dará clic sobre Format.

Se elegirán las opciones necesarias:

Capacity: tamaño que se desea que tenga la unidad a formatear.

File System: tipo de Formato (NTFS o FAT)

Allocation unit Size: tamaño de bloque a definir (va desde 512 bytes hasta los 64K).

Format options: opción para formatear. Si se elige Quick Format los archivos existentes en el disco van hacer retirados, pero no se evaluarán los posibles sectores defectuosos del disco y si se marca Enable Compression, se comprimirán los archivos para ser eliminados.


CIBERTEC

2. Arreglo de disco

Antes de conocer cuáles son los distintos tipos de RAID que existen para una distribución de disco en el motor de base de datos, primero se empezará diciendo que RAID es un conjunto de redundante de discos independientes (Redundant Array of Indeoendent Disk). El concepto de RAID se basa en el almacenamiento de la data en un arreglo de discos para mejorar la performance que solo tendría un disco duro. Adicional a esto, la PC asume este arreglo como una sola unidad lógica o disco. Cabe mencionar que RIAD se diseñó para mejorar la fiabilidad de los datos, un mejor desempeño de I/O, mejorar la tolerancia a fallos y errores. Existen 10 niveles de RAID, que va desde RAID nivel 0, RAID nivel 1… hasta RAID nivel 10. Entre ellos, los más usados son los que se mencionan a continuación.

RAID 0 o sin paridad: proporciona un mejor rendimiento y almacenamiento pero no contiene tolerancia a fallos, es decir, que si un disco falla, se perderá toda la información. Este arreglo está recomendado para cualquier aplicación que utilice gran cantidad de ancho de banda como son las aplicaciones de manipulación de videos.

rhurtado

Resaltado


CIBERTEC

RAID 1: proporciona una mejor tolerancia a fallos; es comúnmente conocida como RAID Mirror. Asimismo, facilita una copia idéntica al disco seleccionado, ya que todos los datos que se escriben en el disco principal se escriben en el disco seleccionado. Este arreglo está recomendado para aplicaciones financieras o de oficina.

RAID 5: posee la más alta tasa de lectura de datos y en caso de fallos, se requiere una unidad de reemplazo. Si un disco falla, las posteriores lecturas pueden calcularse por las paridades distribuidas, de tal forma que la unidad siempre está enmascarando el fallo para los usuarios finales. Este tipo de arreglos se recomienda para los sistemas de Datamart.

RAID 1 + 0: incluye la tolerancia a fallos y mejora en rendimiento. Pero su configuración es más compleja.


CIBERTEC

3. Diseño de la TempDB

TempDB almacena también, información de objetos internos creados por el motor como son las tablas de almacenamiento de información para atender solicitudes de cursores. Debido a esto, muchas veces, existen problemas de lentitud, originados por las transacciones que trabajan con esta base de datos. Es importante tener en cuenta la ubicación y tamaño de la Tempdb para evitar cuellos de botellas cuando se deseen realizar transacciones; por ello, es necesario considerar algunos puntos para mejorar la performance al momento de utilizar la Tempdb.

3.1 Modelo de recuperación y ubicación de la Tempdb Es recomendado configurar el modelo de recuperación de la base de datos Tempdb en modo Simple, para evitar que el Log de transacciones crezca o se mantenga con información que es utilizada de forma temporal. También, se recomienda que esta base de datos, tenga una unidad independiente de las utilizadas para colocar las base de datos del usuario y los datafile de log de dichas bases. Esto debido a que es una base de una escritura constante y el acceso a disco debe ser el apropiado. Además, si la Tempdb crece por alguna mala manipulación de objetos temporales, esto no afectará el proceso de escritura en la base de datos de usuario. Con el siguiente comando, se podrán mover los datafile de la base de datos Tempdb.

ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'E:\SQLData\tempdb.mdf') GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'E:\SQLData\templog.ldf') GO


CIBERTEC

Cabe indicar que cuando se ejecute este movimiento, para que tome efecto el cambio se tendrán que reiniciar los servicios del motor de base datos.

3.2 Tamaño inicial de Tempdb Es recomendado que el tamaño inicial de la base de datos Tempdb sea del 15% al 25% del tamaño total de todas las base de datos almacenadas en el servidor de base de datos. Esto, con el propósito de evitar que Tempdb se expanda con frecuencia y afecte la performance de la aplicación. Estos crecimientos automáticos deben hacerse en números enteros; por ello, es recomendable evitar que Tempdb crezca en %, además, su crecimiento tiene que ser en múltiplos de 2 Mb.

3.3 Un dataFile de Tempdb por cada procesador Es recomendado generar un datafile en Tempdb por cada procesador del servidor con el objetivo de maximizar la afinidad del CPU, esto significa que las operaciones de entrada y salida puedan paralelizarse y así obtener un mejor rendimiento. Sería preferible que cada datafile agregado, tenga su propio disco y con esto, se estaría optimizando al máximo el acceso a los discos. Se recomienda, también, que los data file agregados tengan el mismo tamaño y mismo crecimiento con el fin de maximizar el proceso de llenado en Tempdb. El siguiente script ayuda a visualizar el tamaño actual, cantidad de datafile y crecimiento de Tempdb.

Al ejecutar el script, se podrá ver lo siguiente.

SELECT name AS FileName, size*1.0/128 AS FileSizeinMB, CASE max_size WHEN 0 THEN 'Autogrowth is off.' WHEN -1 THEN 'Autogrowth is on.' ELSE 'Log file will grow to a maximum size of 2 TB.' END Autogrow, growth AS 'GrowthValue', 'GrowthIncrement' = CASE WHEN growth = 0 THEN 'Size is fixed and will not grow.' WHEN growth > 0 AND is_percent_growth = 0 THEN 'Growth value is in 8-KB pages.' ELSE 'Growth value is a percentage.' END FROM tempdb.sys.database_files order by 1 asc; GO


CIBERTEC

La cantidad de Datafile asociado a esta base de datos Tempdb, corresponde a la cantidad de procesadores que se tiene en el servidor.


CIBERTEC

4. Diseño de Base de datos

Cuando se desea crear una base de datos, por lo general se piensa en cómo se llamará y en qué servidor se alojará, y sobre esto se determina si se tiene espacio en disco para poder crearla. Sin embargo, las consideraciones a tener en cuenta son:

El tamaño proyectado que va a tener la base de datos.

La velocidad con la que se accederá a la información.

La velocidad con la que podrá ingresar la información.

El tipo de información que almacenará la base de datos. Además, se puede decir que uno de los pasos más importantes en la creación de una aplicación que maneja una base de datos es el diseño de la misma, ya que si no se tiene en cuenta las buenas definiciones de las tablas, tipos de datos y ubicación de la base de datos, es muy probable tener problemas de performance al momento de utilizar una aplicación.

4.1 Capacity Planning Cuando se tiene la necesidad de crear una base de datos, se debe realizar un análisis sobre los recursos con los que cuenta (CPU, Memoria y disco). 4.1.1. Tamaño del servidor:

No existe un servidor de tamaño estándar que se deba comprar para cubrir la necesidad de crear una nueva aplicación, pero sí existen ciertas preguntas a realizarse: ¿Cuántos usuarios se conectarán al servidor? ¿Cuánta base de datos soportará el servidor? ¿Cuántas transacciones se harán? Asimismo, se deberá tener en cuenta, el número de registros de la tabla más grande. Aunque las variables para determinar el tamaño del servidor se hace cada vez más grande, según la cantidad de carga que soporte el objetivo.


CIBERTEC

4.1.2 Tamaño de nuestra base de datos

La única forma de determinar el tamaño correcto de una base de datos, consiste en determinar las necesidades futuras, para lo cual, las base de datos existentes pueden ayudar a tener un estimado de línea base, no solo en capacidad del servidor sino también en rendimiento como son CPU y Memoria. Hay varias formas de determinar el tamaño de las bases de datos y una vez esto, se podrán determinar requerimientos de tamaño futuro. El siguiente script proporciona el tamaño actual de las bases de datos en el servidor.

CREATE PROC [dbo].[dba_CapacityPlanning] AS BEGIN SET NOCOUNT ON IF NOT EXISTS (SELECT * FROM MSDB.sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_CapacityPlanning]') AND type in (N'U')) BEGIN CREATE TABLE [msdb].[dbo].[tbl_CapacityPlanning] ( [ExecuteTime] [datetime] NULL, [SQLBuild] [nvarchar](57) NULL, [SQLName] [nvarchar](128) NULL, [DBName] [sysname] NULL, [LogicalFileName] [sysname] NULL, [DBCreationDate] [datetime] NULL, [DBRecoveryModel] [nvarchar](60) NULL, [DBCompatibilityLevel] [tinyint] NULL, [DBCollation] [sysname] NULL, [FileType] [nvarchar](60) NULL, [FileName] [nvarchar](260) NULL, [Growth] [float] NULL, [GrowthType] [varchar](30) NULL, [FileID] [int] NULL, [IsPrimaryFile] [bit] NULL, [MaxSize(MB)] [float] NULL, [Size(MB)] [float] NULL, [UsedSpace(MB)] [float] NULL, [AvailableSpace(MB)] [float] NULL, [FileStatus] [nvarchar](60) NULL, [IsOffline] [bit] NULL, [IsReadOnly] [bit] NOT NULL, [IsReadOnlyMedia] [bit] NULL, [IsSparse] [bit] NULL ) ON [PRIMARY] END

CREATE table #tmpspc (Fileid int, FileGroup int, TotalExtents int, UsedExtents int, Name sysname, FileName nchar(520)) DECLARE @DatabaseName varchar(500) DECLARE curDB cursor for SELECT ltrim(rtrim(name)) from master.sys.databases where state_desc='ONLINE' AND user_access_desc='MULTI_USER' open curDB fetch curDB into @DatabaseName while @@fetch_status = 0 begin insert into #tmpspc exec ('USE [' + @DatabaseName + '] DBCC SHOWFILESTATS') fetch curDB into @DatabaseName end close curDB deallocate curDB create table #tmplogspc (DatabaseName sysname, LogSize float, SpaceUsedPerc float, Status

bit) insert #tmplogspc EXEC ('dbcc sqlperf(logspace)') insert into [msdb].[dbo].[tbl_CapacityPlanning] SELECT getdate() AS [ExecuteTime], left(@@version,57) AS [SQLBuild], @@servername AS [SQLName], sd.name AS [DBName], s.name AS [LogicalFileName], sd.create_date AS [DBCreationDate], sd.recovery_model_desc AS [DBRecoveryModel], sd.compatibility_level AS [DBCompatibilityLevel], sd.collation_name AS [DBCollation], s.type_desc AS [FileType], s.physical_name AS [FileName], CAST(CASE s.is_percent_growth WHEN 1 THEN s.growth ELSE (s.growth*8)/1024 END AS float) AS [Growth], CAST(CASE WHEN s.is_percent_growth=1 THEN '%' Else 'MB' END AS VARCHAR) AS [GrowthType], s.file_id AS [FileID], CAST(CASE s.file_id WHEN 1 THEN 1 ELSE 0 END AS bit) AS [IsPrimaryFile], CASE when s.max_size=-1 then -1 else (s.max_size * CONVERT(float,8))/1024 END AS [MaxSize(MB)], (s.size * CONVERT(float,8))/1024 AS [Size(MB)], (CAST(tspc.UsedExtents*convert(float,64) AS float))/1024 AS [UsedSpace(MB)], ((tspc.TotalExtents - tspc.UsedExtents)*convert(float,64))/1024 AS [AvailableSpace(MB)], s.state_desc AS [FileStatus], CAST(case s.state when 6 then 1 else 0 end AS bit) AS [IsOffline], s.is_read_only AS [IsReadOnly], s.is_media_read_only AS [IsReadOnlyMedia], s.is_sparse AS [IsSparse] FROM master.sys.master_files AS s INNER JOIN master.sys.databases sd ON sd.database_id=s.database_id INNER JOIN #tmpspc tspc ON ltrim(rtrim(tspc.FileName)) = ltrim(rtrim(s.physical_name)) UNION ALL SELECT getdate() AS [ExecuteTime],left(@@version,57) AS [SQLBuild], @@servername AS [SQLName], sd.name AS [DBName], s.name AS [LogicalName], sd.create_date AS [DBCreationDate], sd.recovery_model_desc AS [DBRecoveryModel], sd.compatibility_level AS [DBCompatibilityLevel], sd.collation_name AS [DBCollation], s.type_desc AS [FileType], s.physical_name AS [FileName], CAST(CASE s.is_percent_growth WHEN 1 THEN s.growth ELSE (s.growth*8)/1024 END AS float) AS [Growth],


CIBERTEC

Este script crea un procedimiento almacenado que guarda el tamaño actual de la base de datos, en una tabla llamada dba_CapacityPlanning en la base de datos MSDB. Este procedimiento se puede utilizar todas las veces necesarias y almacenará el conjunto de datos en la tabla con la fecha de ejecución, así se podrá saber el tamaño de la base de datos en un momento en el tiempo. Tambien podrá servir para determinar una progresión del tamaño de la base de datos en el tiempo.

4.2 Diseño Conceptual, Lógico y Físico de la base de datos

Si se parte con un mal requerimiento de la nueva base de datos, se tiende a realizar un mal diseño lógico de lo que será una base de datos y con esto, se tendrá un mal diseño físico, lo que conlleva a un mal rendimiento de dicha base de datos. Entonces para hacer bien esto, se deberá conocer qué es el modelo conceptual, lógico y físico.

Modelo Conceptual: determina todos los requerimientos de la base de datos.

Modelo Lógico: es donde se transforman todas las necesidades de la nueva base de datos a entidades, con sus respectivos atributos.

Modelo Físico: es donde se transforman las entidades y atributos en tablas con sus campos. En esta parte también se crean las relaciones entre tablas y las llaves primarias.

CAST(CASE WHEN s.is_percent_growth=1 THEN '%' Else 'MB' END AS VARCHAR) AS [GrowthType], s.file_id AS [FileID],'0' as [IsPrimaryFile],CASE when s.max_size=-1 then -1 else (s.max_size * CONVERT(float,8))/1024 END AS [MaxSize(MB)], (s.size * CONVERT(float,8))/1024 AS [Size(MB)], (tspclog.LogSize * tspclog.SpaceUsedPerc * 10.24)/1024 AS [UsedSpace(MB)], ((s.size * CONVERT(float,8))/1024 - (tspclog.LogSize * tspclog.SpaceUsedPerc * 10.24)/1024) AS [AvailableSpace(MB)], s.state_desc AS [FileStatus], CAST(case s.state when 6 then 1 else 0 end AS bit) AS [IsOffline], s.is_read_only AS [IsReadOnly], s.is_media_read_only AS [IsReadOnlyMedia], s.is_sparse AS [IsSparse] FROM master.sys.master_files AS s INNER JOIN master.sys.databases sd ON sd.database_id=s.database_id INNER JOIN #tmplogspc tspclog ON tspclog.DatabaseName = sd.name WHERE (s.type = 1 ) ORDER BY sd.name, FileID ASC DROP TABLE #tmpspc DROP TABLE #tmplogspc END


CIBERTEC

4.3 Ubicación de archivos y tablas

Una vez desarrollados los modelos lógico y físico, se deberá planear cuál será la ubicación de los archivos y tablas, ya que dependiendo de la facilidad de acceder a la información, se podrá tener una buena performance en la aplicación. Entonces, las buenas prácticas indican que se deberá:

Tener un FileGroup como discos dedicados a la base de datos que tenga el servidor

Contar con una datafile, por cada FileGroup definido.

Ubicar tablas maestras en distintos FileGroup, para mejorar el acceso a la información.

4.4 Normalizar las tablas

Esto permite minimizar el tamaño utilizado por la base datos, además de asegurar la integridad de la información y mejorar el tiempo que pueden tomar las transacciones, puesto que éstas se hacen, generalmente, entre tablas que contienen un número elevado de registros.

capítulo 1 - diseño de base de datos

Documents