ESCUELA POLITCNICA NACIONAL

INGENIERIA EN SISTEMAS INFORMATICOS Y DE COMPUTACION ADMINISTRACIN DE BASES DE DATOS PEORES PRCTICAS DE UN DBA

ADB1
AGUAYO PAUL VSQUEZ ROBERTO VELASCO BYRON

15 de febrero 2012

6.- USO DE VOLMENES RAID APLICACIONES DE USO INTENSIVO.

PARA

ESCRIBIR

El Raid 5 utiliza una divisin de datos a nivel de bloques distribuyendo la informacin de paridad entre todos los discos miembros del conjunto, se implementa con soporte hardware para el clculo de la paridad. En el momento en el que un bloque de datos es escrito en un Raid 5, se genera un bloque de paridad dentro de la misma divisin (stripe). Un bloque est compuesto de muchos sectores consecutivos de disco. Una serie de bloques (un bloque de cada uno de los discos que componen el Raid 5) se denomina colectivo de divisin (stripe). El disco utilizado por el bloque de paridad est escalonado de una divisin a la siguiente (bloques de paridad distribuidos). La escritura en un Raid 5 es costosa en trminos de operaciones de disco y trfico entre los mismos y la controladora, ya que si otro bloque, o alguna porcin del mismo, es escrita en esa misma divisin, el bloque de paridad es recalculado y vuelto a escribir. Al someter a un Raid 5 a cargas de trabajo intensivas su rendimiento es malo, debido a que la paridad debe ser actualizada para cada escritura, lo que exige realizar secuencias de lectura, modificaciones y escritura tanto para el bloque de datos como para el de paridad. RAID-5 tiene un defecto conocido como el agujero de escritura RAID-5, por el que cada vez que se actualicen los datos de una banda RAID deber actualizarse tambin la paridad para que el valor XOR de todos los discos sea cero, se trata de la ecuacin que permite reconstruir los datos cuando falla un disco. El problema es que no hay forma de actualizar dos o ms discos atmicamente, y eso hace que las bandas RAID resulten daadas por un choque elctrico o un apagn. Veamos esto con un ejemplo; suponga que la luz se corta despus de haber escrito un bloque de datos pero antes de escribir el bloque de paridad correspondiente. En tal caso tendremos que los datos y la paridad de la banda no son coherentes entre s, y permanecern as para siempre (a menos que en algn momento consiga escribir una banda completa sobre los datos antiguos). De lo que se deduce que, si un disco falla, el proceso de reconstruccin de RAID generar basura tan pronto como se intente leer cualquier bloque de la misma banda. Y lo peor de todo es que lo har tan en silencio y sin la menor idea de que los datos que facilita no son correctos.

SOLUCIN La utilizacin de RAID Z que es un esquema de datos/paridad igual que el sistema RAID-5, pero con un ancho de banda dinmico. Cada bloque, sea cual sea su tamao, tiene una banda RAID-Z propia, lo que significa que cada escritura RAID-Z es una escritura de banda completa. Cuando esto se combina con la semntica transaccional "copiar al escribir" de ZFS, se elimina totalmente el agujero de escritura RAID. Adems, RAID-Z es incluso ms rpido que el sistema RAID tradicional porque no tiene que "leer-modificar-escribir". Las bandas son todas de tamaos distintos, lo que quiere decir que no existen frmulas de tipo "poner todos los valores XOR de los discos a cero". Ni es necesario atravesar el sistema de archivos de metadatos para determinar la geometra RAID-Z. Tenga en cuenta que esto sera imposible si el sistema de archivos y la matriz RAID fueran productos independientes... y he aqu la razn de que no haya nada que iguale a RAID-Z en el mercado del almacenamiento actual. Lo que en verdad necesita es una visin integrada de la estructura lgica y fsica de los datos para hacer que funcione, pero mucho ms importante todava es que, a medida que atraviesa los metadados, ZFS puede validar cada bloque al compararlo con una suma de comprobacin de 256 bits. Los productos RAID tradicionales no pueden hacer esto; se limitan a agrupar a ciegas los XOR de los datos. Sin embargo, el punto ms importante de RAID-Z es... la auto sanacin de los datos. Adems de poder gestionar un error total de disco, RAID-Z es capaz de detectar y corregir la corrupcin silenciosa de los datos. Cada vez que se lee un bloque RAID-Z, ZFS lo compara con su propia suma de comprobacin. Si los datos del disco no devuelven una respuesta correcta, ZFS lee la paridad y lleva a cabo la reconstruccin del proceso para averiguar qu disco ha devuelto los datos incorrectos. A continuacin, repara el disco daado y enva los datos correctos a la aplicacin. ZFS se encarga tambin de informar del incidente a travs de Solaris FMA para que el administrador del sistema sepa que uno de los discos est fallando.

22.-NO EVALUAR EL USO DE NDICES Y/O FRAGMENTACIN, COMO PARTE DE UNA MANTENIMIENTO DE NDICES. MANTENIMIENTO DE NDICES:

NIVELES RUTINA

DE DE

Los ndices son los nicos objetos que pierden su efectividad con el paso del tiempo si no se le da un mantenimiento adecuado. La fragmentacin de los ndices tiene lugar cuando se modifican los registros de una tabla por insercin, update o borrado de datos y estas modificaciones afectan a una o ms pginas del ndice. Existen dos tipos de fragmentacin a nivel de ndice, ambas afectan directamente la performance de los procesos que utilizan los mismos, veamos: 1.- Fragmentacin Interna: es el tipo de fragmentacin que tiene lugar cuando se lleva a cabo una operacin de borrado. El borrado de datos genera liberacin de espacio en las pginas de ndice, lo que produce que slo una parte de la pgina del ndice est ocupada. Esto provoca que el SQL Server con el tiempo tenga que leer ms pginas de ndice que las necesarias, por el mal aprovechamiento que implica tener pginas de ndice semi vacas. 2.- Fragmentacin Externa: cuando llevamos a cabo un insert y la pgina no puede almacenarse, el SQL Server genera una nueva pgina para alojar los datos insertados, conservando un orden lgico, pero no un orden fsico en las pginas de ndice, a esto se lo conoce como page split. Cuando el SQL Server hace un page split est generando fragmentacin externa. Qu nos dice Microsoft en torno a los niveles de fragmentacin? A- Fragmentacin Inocua: Microsoft dice que no debiramos estar preocupados por la eventual fragmentacin de ndices que contienen menos de 1000 pginas. Este es todo un parmetro a tener en cuenta. Tambin nos habla de no tomar en cuenta la fragmentacin existente sobre tablas pequeas ya que las mismas no tienen impacto sobre la performance de las queries y son muy difcil de ser eliminadas por rutinas de reorganizado o reconstruccin de ndices. B- Fragmentacin Baja: es aquella que no supera el % 5 del ndice. La recomendacin es no intentar eliminar la misma, pues puede ser mayor el costo de hacerlo que los beneficios obtenidos como consecuencia de ello. C- Fragmentacin Media: es la fragmentacin > % 5 y < = al %30: Microsoft recomienda hacer un Reorganize de los ndices. D- Fragmentacin Alta: es la fragmentacin >= al % 30: Microsoft recomienda hacer un Rebuild de los ndices SOLUCIN: Debemos evaluar el uso de ndices y los niveles de fragmentacin como una rutina de mantenimiento de ndices. Definir adecuadamente el tipo de ndice y las columnas a aplicar es clave para mejorar el rendimiento. Hay que identificar cuales tablas se benefician de un ndice y cules no y qu tipo de ndice es el que ms conviene.

Existen varios mtodos para desfragmentar ndices, es importante elegir el mtodo adecuado acorde al entorno de aplicacin del mismo. 1.- Alter Index Reorganize. Se recomienda usar este mtodo cuando el porcentaje de fragmentacin es > % 5 y < = al %30: Se utiliza la instruccin Alter Index con la clasula Reorganize. La reorganizacin se realiza en lnea ya que no mantiene grandes bloqueos. Este proceso utiliza una mnima cantidad de recursos del sistema. Bsicamente se desfragmentan los ndices, se compactan las pginas vacas acordes al valor de fill factor y reordenan la pginas de ndices a nivel fsico, para que coincidan con el ordenamiento a nivel lgico. Para reorganizar las pginas de un ndice particionado en una de las particiones, se debe utilizar la clusula PARTITION. Alter Index Nombre_Idx on Nombre_Tabla Reorganize; 2. - Alter Index Rebuild / Create Index with Drop_Existing = on Se regenera el ndice en su totalidad respetando el fill factor y, salvo que se ordene lo contrario, se hace un update de las estadsticas. Es una operacin que demanda muchos recursos del sistema puesto que el motor de base de datos requiere el doble de espacio del que ocupa el ndice para crear primero el ndice nuevo y luego borrar el viejo. Adems se toma un espacio adicional para hacer esta operacin en el disco salvo que se le indique hacer el ordenamiento en la TempDb. Se usa slo para reconstruir ndices cuyo porcentaje de fragmentacin est por sobre el 30%. Puede ser realizada en lnea excepto que el ndice est sobre columnas de tipo LOB (image, text, nvarchar, xml, varchar(max)), o que sean ndices XML. Se puede hacer un Rebuild de un ndice con la clusula PARTITION, slo en el caso del mtodo Alter Index. Alter Index Nombre Indice on Nombre_Tabla REBUILD; Create Index Nombre_IDX on Table_Name(nombre campo) with Drop

3.- Disabling Indexes Es el mtodo de reconstruccin total de un ndice que menos recursos consume. Al deshabilitar un ndice se impide que el usuario tenga acceso al mismo y a las tablas subyacentes. Esto hace que solo pueda ser usado en ambientes que permitan un downtime, una ventana de mantenimiento. No requiere a diferencia de la sentencia Rebuild del doble de espacio en disco que usa el ndice, puesto que la definicin del ndice se conserva en los metadatos eliminndose fsicamente el mismo. Estas seran las sentencias: Alter Index Nombre_Indice Clustered on Nombre_Tabla DISABLE; Alter Index ALL on Nombre de Tabla REBUILD with (fillfactor = xx, sort in TempDb = On);

14.- COLOCAR LOS DATOS DEL REGISTROS DE TRANSACCIONES EN EL MISMO DISCO FSICO
REGISTROS DE TRANSACCIONES Todas las bases de datos de SQL Server tienen un registro que incluye todas las transacciones y modificaciones realizadas por cada una de las transacciones en la base de datos. El registro de transacciones es un componente esencial de cualquier base de datos; su conocimiento y administracin es una parte importante de la funcin de los administradores de bases de datos. Si en la base de datos existen una gran cantidad de transacciones es de suma importancia que dicho registro de transacciones se saque una copia de seguridad de manera peridica. Esta copia de seguridad sirve para hacer una recuperacin completa de las transacciones. SOLUCIN Este registro dado la importancia que tiene se lo debe almacenarlo en cualquier otro lugar que no sea dentro del mismo servidor, para minimizar los riesgos de daar el registro de transacciones, se recomienda ubicar el registro de transacciones en un medio de almacenamiento con tolerancia a errores, como los discos reflejados, medios de almacenamiento externo que cuente con el espacio necesario para almacenar dicho registro. Adems ya que los registros de transacciones pueden llegar a tener un tamao demasiado grande y provocar que la capacidad de almacenamiento del disco fsico disminuya considerablemente, se debe realizar un truncamiento ya que es fundamental evitar que el registro se llene por completo.

BIBLIOGRAFIA http://www.infodata.es/tour/raid-5.html https://blogs.oracle.com/bonwick/es/entry/raid_z2 http://gherrerasqlserver.blogspot.com/2011/07/mantenimiento-de-indices.html http://technet.microsoft.com/es-es/library/ms345382.aspx