Diseo y Arquitectura de Base de Datos

Al finalizar el captulo, el alumno podr:

Reconocer los distintos formatos de disco.

Definir la mejor arquitectura para poder crear una base de datos.
Elegir el mejor arreglo de disco para el propsito de su base de datos.
Aplicar la mejor distribucin de sus objetos de base de datos.

Temas:

1. Formateo y Alineamiento de Disco

2. Arreglo de Disco

3. Diseo de la Base de datos TEMPDB

4. Diseo de Base de datos

1. Formateo y Alineamiento de Disco

Muchas veces cuando queremos mejorar nuestros tiempos de I/O

(entradas y salidas de disco) los factores que tomamos en cuenta
son: velocidad y tamao de disco, si los discos son dedicados,
compartidos, virtuales o el tipo de RAID. Pero lo que no consideramos
es la alineacin y formateo de disco. El contar con nuestras
particiones alineadas mejora en un 30% o 40% el rendimiento de
nuestros sistemas.
1.1 Alineamiento de Disco
La pgina es la unidad bsica del almacenamiento da datos en SQL
Server. El espacio en disco asignado a un archivo de datos (.mdf o
.ndf) de una base de datos se divide lgicamente en pginas
numeradas de forma contigua de 0 a n. Las operaciones de E/S de
disco se realizan a nivel de pgina. Es decir, SQL Server lee o escribe
pginas de datos enteras. El tamao de pgina es de 8 KB. Esto
significa que las bases de datos de SQL Server tienen 128 pginas
por megabyte. Existen 3 datos importantes para alinear nuestras
particiones
Partition Offset: Es el tamao del primer sector y a partir de
este empieza las particiones, esto garantiza la omisin de
asignacin de pginas en este sector (Este sector es creado
por el hadware de almacenamiento). El Partition Offset alberga
MBR (Master Boot Record) de 512KB, Tabla de particiones, la
firma del disco y los cdigos de maquina que se encargan de
 recibir el control de la BIOS. La primera particin no empieza
despus de esta particin, sino que se reserva un nmero de
sectores siguientes. Esto es en los sistemas operativos,
Windows, que reportan un numero de sectores ocultos (63
sectores)
Stripe Unit Size: Los controladores de disco definen un tamao
mnimo para cada una de las bandas que se utilizaran para
almacenar datos y paridades en los sistemas de RAID esto es
en los sistemas en los que los volmenes comprende mas de
un disco fsico. Estas bandas comprenden un cierto nmero
de sectores de disco y su tamao ser mltiplo de la cantidad
de sectores de disco. En los sistemas operativos Windows el
Windows Volume Manager define un valor de 64k para el
Stripe Unit Size.
Allocation Unit: Es el menor tamao posible que puede ocupar
un fichero. Su valor se puede especificar explcitamente a la
hora de formatear. En NTFS es de 4K y toma un valor
maximo de 64K.
Ahora, el alineamiento de las particiones se base en buscar una
buena relacin entre estos tres datos, de manera que las operaciones
de lectura/escritura no busquen la data en ms de un disco que
conforman el volumen. Esto lleva a que al momento de leer o escribir
tengamos que hacerlo en diferentes discos y la acumulacin de esto
hace que perdamos performance. Para evitar esto las siguientes
relaciones deben de entregar un nmero entero
Partition Offset / Stripe Size Unit
Stripe Size Unit / Allocation Unit
Ejemplo 1
Supongamos que nuestro servidor de produccin tiene problemas de
performance.
Primero verifiquemos el tamao del Partition Offset:
Entramos al Menu Inicio\Ejecutar y escribimos
Cmd
Luego escribimos
C:\\Windows\\System32
Y estando es esta carpeta escribimos
Wmic partition get BlockSize, StartingOffset, Name, Index
Esto nos devolver el tamao del StartingOffSet

Ahora, para hacerlo mas simple podemos dividir el valor del

StartingOffSet entre 1024 y si el valor devuelto es entero entonces
podemos indicar que nuestra particin esta alineada.
Si el valor devuelto no fuera entero entonces se ingresar por el
Men Inicio\Ejecutar luego escribimos regedit
Y nos ubicamos en la carpeta
\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Serv
ices\vds\Alignment
Luego todas las variables las alineamos a 1024Mb o (1048576 bytes)

1.2 Formatear un Disco

Formatear un disco significa borrar todo los que contiene y esto se
puede hacer en dos formatos NTS y FAT32. Los formatos significan la
forma en que los discos guardaran su informacin.
El formato NTFS se puede utilizar a partir de Windows 2000 en
adelante y la FAT32 no permite tener archivos mayores a 4GB
El Formato del disco permite definir el tamao lgico del sector o
bloque y esto es independiente del tamao de la particin. Los
formatos NTFS permiten utilizar tamao que van desde los 512bytes
hasta los 64K.
Cuando se desea formatear un disco, solo se hace click derecho
sobre la unidad que queremos formatear
Luego, se dar clic sobre Format.

Se elegirn las opciones que necesarias:

Capacity: Es el tamao que deseamos que tenga la unidad a
formatear
File System: El tipo de Formato (NTFS o FAT)
Allocation Unit Size: El tamao de bloque que deseamos
definir, como mencionamos va desde 512bytes hasta los 64K
Format options: Opcin para formatear, si elegimos Quick
Format los archivos existentes en el disco van hacer retirados
pero no se evaluara lo posibles sectores defectuosos del disco
y si marcamos Enable Compression, se comprimirn los
archivos para ser eliminados.
2. Arreglo de disco

Antes de conocer cuales son los distintos tipos de RAID que existen
para los una distribucin de disco en el motor de base de datos
primero empezaremos diciendo que RAID es un conjunto redundante
de discos independientes (Redundant Array of Independent Disk).
El concepto de RAID se basa en el almacenamiento de la data en un
arreglo de discos para mejorar la performance que solo tendra un
disco duro. Adicional a esto, nuestra PC asume este arreglo como una
sola unidad lgica o disco.
Cabe mencionar que RAID se dise para mejorar la fiabilidad de los
datos, un mejor desempeo de I/O, mejorar la tolerancia a fallos y
errores.
Las caractersticas de los arreglos son:
- Mejorar la tolerancia a fallos y errores.
- Aumentar la integridad de los datos.
- Mejorar el rendimiento de los sistemas.
- Ofrecer una alternativa econmica frente a los sistemas SCSI.
Existen 10 niveles de RAID, que va desde RAID nivel 0, RAID nivel 1
hasta RAID nivel 10.
Entre ellos, los ms usados son los que se mencionan a continuacin:
RAID 0 sin paridad: Proporciona un mejor rendimiento y
almacenamiento pero no contiene tolerancia a fallos, es decir que si
un disco falla perdemos toda la informacin. Este arreglo esta
recomendado para cualquier aplicacin que utilice gran cantidad de
ancho de banda como son las aplicaciones de manipulacin de videos.

RAID 1: Ya que proporciona una mejor tolerancia a fallos; es

comnmente conocida como RAID Mirror. Este arreglo proporciona
una copia idntica al disco seleccionado ya que todos los datos que se
escriben en el disco principal se escriben en el disco seleccionado.
Este arreglo esta recomendado para aplicaciones financieras o de
oficina.

RAID 5: Posee la ms alta taza 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 esta enmascarando el fallo para los usuarios
finales. Este tipo de arreglos se recomienda para los sistemas de
Datamart
RAID 1 + 0: Ya que incluye la tolerancia a fallos y mejora en
rendimiento y su configuracin es ms compleja.
3. Diseo de la TempDB

La TempDB es una base de datos del sistema que se instala por

default y se utiliza para almacenar objetos temporales creados por el
usuario como tablas temporales, vistas temporales, variables
temporales u otro objeto temporal.
Tambin, almacena informacin de objetos internos creados por el
motor, como son las tablas de almacenamiento de informacin para
atender solicitudes de cursores. Debido a esto, muchas veces, nos
encontramos con problemas de lentitud originados por las
transacciones que trabajan con esta base de datos.
Es importante tener en cuenta la ubicacin y tamao de la Tempdb
para evitar cuellos de botella cuando necesitemos realizar nuestras
transacciones, por ello es necesario considerar algunos puntos para
mejorar la performance al momento de utilizar la Tempdb
3.1 Modelo de recuperacin y Ubicacin de la Tempdb
Es recomendado configurar el modelo de recuperacin de la base de
datos Tempdb en modo Simple y con esto evitamos que el Log de
transacciones crezca o se mantenga con informacin que es utilizada
de forma temporal.
Tambin, se recomienda que la base de datos Tempdb tenga una
unidad independiente de las utilizadas para colocar los archivos de las
bases de datos de los usuarios. Esto debido a su naturaleza, de ser
una base de datos con una escritura constante y el acceso a disco
debe ser el ms apropiado para cumplir de manera eficiente estas
escrituras. Adems, si nuestra Tempdb crece por alguna mala
manipulacin de objetos temporales esto no afectara el proceso de
escritura en las bases de datos de usuario
Con el siguiente comando podemos mover los archivos de la base de
datos Tempdb (.mdf/.ndf, .ldf)

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

Cabe indicar que cuando ejecutemos este movimiento, para que tome
efecto tenemos que re-iniciar los servicios del motor de base datos.
3.2 Tamao inicial de la Tempdb
Es recomendado que el tamao inicial de la base de datos Tempdb
sea del 15% al 25% del tamao total de todas las base de datos
almacenadas en nuestro servidor de base de datos. Esto con el
propsito de evitar que la Tempdb se expanda con frecuencia y afecte
la performace de nuestra aplicacin. Estos crecimientos automticos
deben hacerse en numero enteros por eso lo recomendado es evitar
que la Tempdb crezca en % y su crecimiento tiene que ser en
mltiplos de 2 Mb.
3.3 Un DataFile de la Tempdb por cada Procesador
Es recomendado generar un datafile en la Tempdb por cada
procesador del servidor con el objetivo de maximizar la afinidad del
CPU, esto significa que las operaciones de entrada y salida se puedan
llevar a cabo en paralelo y as obtener un mejor rendimiento. Seria
preferible de que cada datafile agregado tenga su propio disco y con
esto se estara optimizando al mximo el acceso a los discos.
Se recomienda, tambin, que los data file agregados tengan el mismo
tamao y mismo crecimiento con el fin que se maximice el proceso
de crecimiento en la Tempdb
El siguiente script nos ayuda a visualizar el tamao actual, cantidad
de datafiles y el crecimiento de la Tempdb

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
Al ejecutar el script podemos ver

La cantidad de datafiles asociados a esta base de datos Tempdb

corresponde a la cantidad de procesadores que tenemos en el
servidor
4. Diseo de Base de datos

Cuando vamos a crear una base de datos, por lo general solo

pensamos en como se va llamar y en que servidor ser alojado,
sobre esto determinamos si tenemos espacio en disco para poder
crearla.
Sin embargo las consideraciones que debemos de tener en cuenta
son:
El tamao proyectado que va a tener nuestra base de datos.
La velocidad con la que se acceder a la informacin.
La velocidad con la que se podr ingresar la informacin
El tipo de informacin que se almacenar en la base de datos.
Adems, se puede decir que uno de los pasos mas importantes en la
creacin de una aplicacin que interactua con una base de datos es el
diseo de la misma, ya que si no se tiene en cuenta unas buenas
definiciones respecto a las tablas, tipos de datos y ubicacin de la
base de datos, es probable tener problemas de performance al
momento de utilizar nuestra aplicacin.
4.1 Capacity Planning
Cuando una tiene la necesidad de crear una base de datos, se tiene
que realizar un anlisis sobre los recursos con los que cuenta (CPU,
Memoria y disco)
4.1.1. Tamao del servidor:
No existe un servidor de tamao estndar que se deba comprar para
cubrir la necesidad de crear una nueva aplicacin. Pero si existen
algunas preguntas que deben de formularse:
Cuntos usuarios se conectaran al servidor?
Cuntas bases de datos soportara el servidor?
Cuantas transacciones se realizarn?
Las bases de datos son OLTP/DWH/SSTD?
Asimismo, se deber tener en cuenta el nmero de registros de la
tabla ms grande.
Aunque las variables para determinar el tamao apropiado del
servidor se hace cada vez ms grande, segn la cantidad de carga
que soporte; el objetivo es comprar algo que cumpla con nuestro
requerimiento sin tener que desperdiciar dinero.
4.1.2 Tamao de nuestra base de datos
La nica forma de determinar el tamao correcto de una base de
datos consiste en determinar las necesidades futuras, para lo cual las
bases de datos existentes pueden ayudar a tener un estimado como
lnea base, no solo en capacidad del servidor sino tambin en
rendimiento como son: CPU y Memoria. Hay varias formas de
determinar el tamao de las bases de datos y una vez obtenida la
informacin se puede determinar los requerimientos de tamao
futuro.
El siguiente script nos proporciona el tamao 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],
 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

Este script crea un procedimiento almacenado que guarda el tamao

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 que sean necesarias y almacenar el conjunto de datos en la
tabla con la fecha ejecucin, asi se podr saber el tamao de la base
de datos en un momento en el tiempo y tambien podr servir para
estimar el tamao de la base de datos en el tiempo
4.2 Diseo Conceptual, Lgico y Fsico de la base de datos
Si se parte con un mal requerimiento de la nueva base de datos, se
tiende a realizar un mal diseo lgico de los que ser la base de datos
y con esto, se tendr un mal diseo fsico lo que conlleva a un mal
rendimiento de la base de datos. Entonces para poder realizar bien
estos pasos se debe de conocer lo que es el modelo conceptual,
lgico y fsico.
Modelo Conceptual.- Determina todos los requerimientos de nuestra
base de datos.
Modelo Lgico.- Es donde se transforma todas las necesidades de la
nueva base de datos a entidades con sus respectivos atributos.
Modelo Fsico.- Es donde se transforman las entidades y atributos en
tablas con sus campos. En esta parte tambin se crean las relaciones
entre tablas y las llaves primarias.
4.3 Ubicacin de Archivos y tablas
Una vez desarrollados los modelos lgico y fsico, se debe planear
cual ser la ubicacin de los archivos y tablas ya que dependiendo de
la facilidad de acceso se puede tener una buena performance en
nuestra aplicacin. Algunas buenas prcticas recomiendan lo
siguiente:
Tener un FileGroup como discos dedicados a la base de datos
tengamos en nuestro servidor.
Contar con una datafile por cada FileGroup definido.
Ubicar las tablas maestras en distintos FileGroups para mejorar el
acceso a la informacin.
4.4 Normalizar las tablas
Normalizar las tablas de una base de datos permite minimizar el
tamao utilizado por la base datos, asegurar la integridad de la
informacin y mejorar el tiempo que pueden tomar nuestras
transacciones ya que estas se hacen generalmente entre tablas que
contienen un nmero elevado de registros.