Archivos de la categoría: Base de datos

Mover base de datos de una region a otra en Azure

Hola mundo:
En esta entrega, revisaremos un procedimiento altamente solicitado por administradores de infraestructura en Azure. Este consiste en migrar una base de datos de una región a otra con muy bajo downtime y, prácticamente, sin pérdida de datos, utilizando la geo replicación y las características de alta disponibilidad.
Para este ejemplo, tendré una base de datos de prueba (AdventureWorks)  en la región East US. Para efectos de la prueba, es una base de datos de bajo costo.
Dentro del panel del recurso, iremos al menú de la izquierda y ubicaremos la opción Geo-Replication
Abrirá una ventana asi. Se muestra un mapa con las regiones disponibles para hacer la replicación

Para hacer la replicación, escogeré la región West US 2 del listado. Una vez seleccionada la región, abrirá un asistente donde se pide configurar algunos parámetros. Entre los parámetros a configurar es la creación de un servidor SQL Server donde residirá la base de datos réplica. 
Una vez seteados los parámetros, la replicación comenzará a ejecutarse:

 
Aparece la base de datos replicada en el apartado de Secondaries y en el mapa se ve una gráfica de la replicación.
Al entrar en la réplica de la base de datos, veremos la opción de hacer un failover forzado.
Al hacer el failover aparece una advertencia diciendo que todas las sesiones van a ser desconectadas y que podría perder datos. Entendiendo los riesgos, procedemos.
Al volver a la vista principal de geo replicación, se ve que el estado de la base de datos secundaria está en proceso de failover.
Luego de esperar el cambio, se puede observar que la base de datos secundaria ya es primaria:
Ahora queda cumplir el cometido: Eliminar la base de datos para que solo quede en una sola region. Para esto hay que ir a la vista de las bases de datos y eliminar la que corresponde. Tomar en cuenta que aparece cual es el rol de la base de datos (primaria o secundaria). 
Confirmación de eliminación
Con este procedimiento, la geo replicación queda desactivada y la base de datos operando en la nueva región.  Es importante cambiar la conexión en las aplicaciones que hagan uso de esta base de datos. Recordar que es un nuevo servidor SQL Server, con un nombre distinto.
Espero que les sea de utilidad.

Recomendaciones para base de datos para SCCM

Hola Mundo:

La implementación de System Center Configuration Manager requiere de un servidor de base de
datos SQL Server y existen recomendaciones para esta implementación, que presentaré las más relevantes.
Servidor dedicado
SCCM es una plataforma que almacena absolutamente todo en base de datos e incluso realiza transacciones sin darnos cuenta. Hay que pensar, que en todo momento se están recibiendo inventarios e información de distribución de paquetes. Aparte, hay que tener que es una herramienta asíncrona y mantiene su propia cola de procesos y transacciones con la base de datos.
Es por eso que siempre tiene muchas conexiones abiertas hacia la base de datos.
Particiones de disco
Como todo servidor de base de datos, la configuración de los discos es vital. Es muy importante que sistema operativo, datos, logs, tempdb y respaldo queden en discos distintos. Incluso, si son máquinas virtuales, los discos virtuales deberían estar en discos físicos distintos. Si se crean los discos duros virtuales en el mismo disco o LUN, las operaciones de las bases de datos harán uso de los recursos de un único disco, impactando el rendimiento.
Collation
El collation de una base de datos SQL Server es cómo el sistema interpreta cada uno de los caracteres que se almacena en la base de datos. SCCM requiere del collation SQL_Latin1_General_CP1_CI_AS. No funciona con otro más.
Cuentas
Al momento de instalar el servidor de base de datos, es altamente recomendado configurar una contraseña para la cuenta SA. Esto facilitará la resolución en caso de problemas. Es recomendado, también, configurar las cuentas de servicio como cuentas de dominio.
Puertos
SCCM no soporta puertos dinámicos de SQL Server. Así que cuando instales una instancia para SCCM, asegúrate que el servicio esté escuchando por el puerto 1433.
Mucho cuidado con las instancias nombradas, ya que tienden a configurarse como puertos dinámicos.

64 bits siempre
La arquitectura de 32 bits no está soportada por la plataforma. Siempre se debe usar SQL Server x64 para que SCCM pueda reconocerlo como un servidor de base de datos compatible. En el caso que no sea así, el programa de instalación dará un mensaje de error de incompatibilidad, aun cuando la versión de SQL Server sea soportada.

Uso de memoria
Siempre establece un mínimo y un máximo de memoria para la instancia. Recuerda que un servidor de base de datos es como un sistema operativo, por lo tanto, el uso de memoria es crítico. Como recomendación, siempre dejar un 10% para procesos propios del sistema operativos. Con esto evitas que la instancia utilice el 100% de la memoria y el servidor se quede sin recursos.

Respaldos
La misma plataforma de SCCM incluye una tarea de mantenimiento del sitio completo, inclusive de

la base de datos. Para que en el caso de recuperación ante un desastre, desde el programa de restauración del sitio, se restaure la base de datos. No está recomendado restaurar la base de datos de forma manual. La tarea de respaldo de SCCM debe ser habilitada.

Monitoreo
Como todo servidor de base de datos, está altamente recomendado contar con una solución de monitoreo de servicios para tener conocimiento del estado real de salud del servicio y del servidor y prevenir cuellos de botella e indisponibilidad del servicio.

CPU
Recomendación obvia, pero de todas maneras hay que mencionarla. Para una implementación de este estilo, mínimo 4 CPU si es una máquina virtual. Con esto se evita cuello de botella en el servidor.

Con estas recomendaciones, tendrás un servidor cercano a las mejores prácticas de funcionamiento e implementación y esto se traduce en un mejor rendimiento de la plataforma de SCCM.

Hasta la próxima.

Delete, Truncate y Drop

Delete From, Truncate Table y Drop Table  son sentencias de SQL que sirven para borrar. Existen en todos los motores de base de datos, pero los tres hacen borrados distintos.

Delete From

Esta sentencia DML se utiliza para eliminar registros según condición, o simplemente, borra todos los registros de la tabla.  No es autocommit, registra todo en el log de transacciones y no altera la estructura de la tabla. Tiene a ser un poco ineficiente al registrar todo. Veamos este ejemplo:

A una tabla con 14 registros, le di la siguiente instrucción:

DELETE FROM Tabla1

Ocurrió lo esperado: Eliminó todos los registros de la tabla y no modificó su estructura. Además, registró todo en el log de transacciones y realizó el commit una vez que ejecutó todos los delete

 

Log transaccional de DELETE FROM

Log transaccional de DELETE FROM

Tomar en cuenta que todo lo que está dentro del cuadrado rojo corresponde a la eliminación de cada uno de los registros de la tabla. Hay una porción destacada en amarillo. Es ahí cuando realiza el commit.

Cuando se elimina un registro en una tabla que tiene un campo como identity el contador nunca más vuelve a usar el registro identity que se eliminó. Por ejemplo:


Numero color
1 blanco
2 rojo
3 azul

y ejecutamos lo siguiente:

DELETE FROM Tabla WHERE Numero = 2

Va a eliminar el segundo registro y al insertar un campo en la base de datos, quedaría así:

Numero color
1 blanco
3 azul
4 amarillo

Al manipular los datos de la tabla, está sujeto a las restricciones de las claves foráneas.

 

Truncate

Truncate Table, sentencia DDL,  elimina todos los registros de la tabla. A diferencia de Delete From, no escribe en el log de transacciones, por lo que no es posible hacer un rollback.  La otra diferencia que tiene con Delete From, es que no ofrece un borrado selectivo y no se le puede pasar un trigget con ON DELETE.
Ejemplo de la imagen:

Ejemplo de Truncate Table

Ejemplo de Truncate Table

Como se puede ver en la imagen, no registra todos los datos que elimina. Lo único que hace es un deallocate.

 

Al borrar los datos de un tabla que tiene una columna como identity, el contador vuelve a cero. Veamos el ejemplo:


Numero color
1 blanco
2 rojo
3 azul

y ejecutamos lo siguiente:

TRUNCATE TABLE Tabla

La tabla quedará vacía y al insertar un registro quedará así:

Numero color
1 verde

Al eliminar registros con esta sentencia, está sujeto a las restricciones de las claves foráneas.

 

Drop

Sentencia DDL, que se utiliza para modificar la estructura de una tabla, por ejemplo al eliminar una columna de una tabla, o bien, eliminar la tabla completa.  Al eliminar la tabla completa, lo primero que hace es hacer un borrado de los registros con DELETE, hace un commit y al final borra la tabla.  El registro es bastante grande, así que me disculparán por no poner un ejemplo.

Espero que esto les haya servido de ayuda.

Instalar base de datos de prueba en SQL Server 2012 RC0

He conocido a mucha gente sequisima en el tema de las bases de datos e informatica en general. Del total, no he conocido a nadie que haya inventado millones de registros para realizar pruebas. Es por esto, que existen las bases de datos de ejemplo para poder hacer pruebas en ambientes mas o menos reales.

Oracle trae los suyos, MySQL tiene uno que otro repartido por internet. PostgreSQL tiene los suyos por ahi. Obviamente, SQL Server tiene los suyos disponibles en http://msftdbprodsamples.codeplex.com.

Sorpresa! Solo descarga un archivo mdf sin un archivo de logs. Por lo que al momento de adjuntar la base de datos, hay que crear un archivo de logs.

Hay que abrir SQL Management Studio y en una nueva consulta escribir lo siguiente:

{{ CREATE DATABASE AdventureWorks2008R2 ON (FILENAME = ‘ruta/al/archivo/AdventureWorks2008R2_Data.mdf’) FOR ATTACH_REBUILD_LOG ;}}

Entonces aquí se indica que cree una nueva base de datos a partir del archivo indicado y que cree un nuevo archivo de logs.