Configurando Database Mail

1.       Abrimos el SQL Server Management Studio.

2.       En el explorador de soluciones vamos a Management,  Database Mail,  click Derecho,  Configure Database Mail.

3.      Nos mostrara un asistente le damos siguiente.

4.      Aquí vamos a seleccionar la opción de configuración inicial.

Nos dira que no tenemos habilitado la opción de Database Mail, le diremos que si

 

5.       En la opción de New Profile,  vamos a especificar un nombre para el profile y agregar un servidor SMTP haciendo click en Add

 

6.       Vamos a configurar el servidor SMTP,  usaremos el servidor de correos de gmail, utilizando una cuenta normal de correo con sus respectivas credenciales.

7.       Una vez que configuramos la cuenta de SMTP,  procedemos al siguiente paso.  Definimos las políticas de seguridad, haciendo público o privado nuestro profile.

8.       En el siguiente paso vamos a configurar valores o parámetros del sistema, como numero de intentos al fallar el envio, la cantidad de tiempo que espera entre envíos, archivos Attach

9.   Finalmente le damos finalizar a nuestro asistente creando nuestro nuevo profile y configurando nuestra cuenta SMTP.

 

 

10.       Ahora probaremos nuestra configuración a ver si es la correcta.  Hacemos click derecho sobre Database Mail y seleccionamos la opción “Send E-mail Test”

  

11.       Verificamos si envio correctamente el correo,  click derecho sobre Database Mail  y seleccionamos “View database Mail Log”

 

12.       En mi correo personal ya tengo el correo que se envío hace 1 minuto atrás.

 

 

13.       Excelente,  una vez que tenemos probado nuestro server y cuenta SMTP, procederemos a enviar correos por medio de T-SQL.  Importante estar siempre dentro de la base msdb.

USE msdb

EXEC sp_send_dbmail @profile_name='profile01',

@recipients='juan.perez@hotmail.com',

@subject='Prueba de Envio de Correo por SQL Server',

@body='Este es el cuerpo del correo de prueba felicidades Database Mail funciona correctamente.'

14.       Podemos revisar la bitácora de correos enviados,  y bitácora de eventos en las siguientes tablas:

SELECT * FROM sysmail_mailitems

GO

SELECT * FROM sysmail_log

Operadores INTERSECT, EXCEPT y UNION

INTERSECT, EXCEPT y UNION  son un set de operadores que ejecutan operaciones entre 2 o más set de datos.   UNION ha estado disponible en T-SQL desde las primeras versiones,  mientras INTERSECT y EXCEPT fueron introducidos en SQL 2005.     Los tres operadores tienen requerimientos similares:

1.       Requieren un mínimo de 2 set de datos.

2.       Cada set de datos debe tener el mismo número de columnas.

3.       Cada columna con su relativa columna deben ser tipos de datos compatibles.

4.       La cláusula ORDER BY puede usarse únicamente al final de la consulta.

UNION

Combina los resultados de dos o más consultas en un solo conjunto de resultados que incluye todas las filas que pertenecen a las consultas de la unión.

SELECT A, B, C  FROM TABLA1

UNION

SELECT A, B, C  FROM TABLA2

Una variante es UNION ALL  que agrega todas las filas a los resultados. Incluye las filas duplicadas. Si no se especifica, las filas duplicadas se quitan.

SELECT A, B, C  FROM TABLA1

UNION ALL

SELECT A, B, C  FROM TABLA2

INTERSECT

Devuelve los valores distintos de la consulta inicial que corresponda con la siguiente consulta.  Es decir los valores en común que tengan ambas consultas.

SELECT A, B, C  FROM TABLA1

INTERSECT

SELECT A, B, C  FROM TABLA2

EXCEPT

Devuelve los valores distintos de la consulta inicial que no se devuelven desde la consulta siguiente.   Es decir en dependencia de la ubicación de la consulta nos regresara los valores que no se encuentren la siguiente.

SELECT * FROM t1

EXCEPT

SELECT * FROM t2

Sera distinto los resultados para la siguiente consulta:

SELECT * FROM t2

EXCEPT

SELECT * FROM t1

DIFERENCIA SIMETRICA

Como lograriamos esta consulta?

Pudiésemos usar NOT IN para ello

SELECT A

     FROM Tabla1

     WHERE A NOT IN(SELECT A FROM Tabla2)

     UNION

     SELECT A

     FROM Tabla2

     WHERE A NOT IN(SELECT A FROM Tabla1)

O bien lo hariamos con la combinacion de los operadores antes vistos:

 SELECT A FROM TABLA1

     UNION

 SELECT A FROM TABLA2

     EXCEPT

 SELECT A FROM TABLA1

     INTERSECT

 SELECT A FROM TABLA2

Tipos de JOIN en T-SQL

INNER JOIN

Permite combinar 2 o más tablas a través de al menos un campo en común.    Es la unión natural entre las tablas.   Los resultados son los datos que tienen un común ambas tablas.

SINTAXIS

SELECT * FROM TABLA1 T1 INNER JOIN TABLA2 T2 ON T1.CampoA = T2.CampoA

LEFT OUTER JOIN

Permite hacer una mezcla y conservar todos los valores de la tabla izquierda (la primera tabla que se menciona en la consulta) sin importar que no tengan equivalente con la de la derecha.  Los resultados serán siempre todos los registros de la tabla izquierda TABLA1  sin que exista coincidencia en la otra tabla TABLA2. 

SINTAXIS

SELECT * FROM TABLA1 T1 LEFT OUTER JOIN TABLA2 T2 ON T1.CampoA = T2.CampoA

RIGHT OUTER JOIN

Permite hacer una mezcla y conservar todos los valores de la tabla derecha (la segunda tabla que se menciona en la consulta) sin importar que no tengan equivalente con la primera.  Los resultados serán siempre todos los registros de la tabla derecha TABLA2 sin que exista coincidencia en la otra tabla TABLA1.   

SINTAXIS

SELECT * FROM TABLA1 T1 RIGHT OUTER JOIN TABLA2 T2 ON T1.CampoA = T2.CampoA

CROSS JOIN

Nos permite hacer un producto cartesiano entre las tablas que estamos comparando.   Es una multiplicación de ambas tablas.   Se puede realizar de manera normal o bien de manera implícita.

---CROSS JOIN NORMAL

SELECT * FROM Tabla1 CROSS JOIN Tabla2

---CROSS JOIN IMPLICITO

SELECT * FROM Tabla1 ,Tabla2 

FULL OUTER JOIN

Es la combinación completa. Nos permitirá hacer una mezcla total y conservar todos los valores de ambas tablas, los valores que no tengan equivalencia aparecerán acompañados de un NULL y se mostraran todos los registros.

 SELECT * FROM Tabla1 FULL OUTER JOIN Tabla2 ON Tabla1.CampoA = Tabla2.CampoA

Configurando Log Shipping

Log Shipping automáticamente envía un backup Transaction Log  de una base de datos primaria en un servidor o instancia primario a una o más bases de datos secundarias.

Log Shipping suporta un tercer servidor o instancia opcional , conocido como “Monitor Server”

 

Log Shipping consiste en 3 operaciones básicas:

1.       Respaldar el Transaction Log en el server primario

2.       Copiar el Archivo Log  en el Servidor Secundario

3.       Restaurar el Log en el Servidor Secundario

  

Configuración

1.       Antes de empezar verifiquemos que nuestros SQL Server Agents se estén ejecutando y tengan permisos suficientes para escribir archivos en el otro server.

2.       El primer paso sería inicializar la base de datos en el servidor secundario con un respaldo del servidor primario, dejar la base de datos el modo RESTORE WITH NORECOVERY.

3.       En el servidor primario crear una carpeta compartida llamada “EnviadosLogShipping”.

4.        En el servidor secundario crear una carpeta compartida llamada “RecibidosLogShipping”.

5.       En el servidor primario con la base de datos a realizar el LogShipping, hacer click derecho y nos vamos a propiedades,  opción “Transaction Log Shipping”, hacemos click en “Enabled this as a primary database in a log shipping configuration”.  Por ultimo click en Backup Settings.

 

    6.       En la configuración definimos la ruta donde dejaremos el archivo log,  la carpeta compartida creada previamente.

 

    7.       Ahora vamos a configurar el servidor secundario, haciendo click en Add

 a

 

    8.       Primero hacemos click en Connect,  y nos conectamos a nuestro server secundario.  Completamos las pestanas tal y como se ve en las capturas siguientes.

    9.       Ahora vamos a verificar que es lo se está ejecutando en nuestro log shipping.  Sobre la base datos de cada servidor,  hacer click derecho,  Reports, Standard Reports,  y seleccionamos el ultimo reporte llamado Transaction Log Shipping Status.  Recodar hacerlo para cada servidor ya que cada uno nos mostrará información complementaria.

 

     10.       Ahora vamos a ver como realizar el switch en el caso de que nuestro server primario “muera” o falle y que nuestro server secundario entre como primario.

RESTORE DATABASE Cuentos WITH RECOVERY

IMPORTANTE:  El servidor primario deberá estar fuera de línea para que no continue enviando respaldos o continue como servidor primario en funcionamiento,  de lo contrario podremos perder información al no saber que servidor es el que esta en producción .

Configurando Database Mirroring

Database Mirroring es una solución de Alta Disponibilidad en SQL Server, disponible desde SQL Server 2005 y sensiblemente mejorada en SQL Server 2008, mostrándose como una alternativa a los sistemas de Alta Disponibilidad basados en Microsoft Cluster y/o Replicación de Almacenamiento Datos, siendo también una alternativa interesante a otras tecnologías como Log Shipping o a la Replicación de SQL Server.


Database Mirroring, al igual que Log Shipping, sólo protege a nivel de base de datos (es decir, sólo las bases de datos de usuario) y no a nivel de Instancia, para lo cual sería necesario implementar Server Clustering (y así proteger también las bases de datos del sistema y demás elementos que forman una instancia de SQL Server).

Database Mirroring es una tecnología de Alta Disponibilidad basada en un modo de funcionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos. En consecuencia, no será posible el acceso a la copia de la base de datos del Servidor Espejo.

Database Mirroring requiere que la base de datos que se desee proteger, esté configurada con el Modo de Recuperación Completo (Full Recover Model), algo bastante evidente, al tratarse de una tecnología que basa su funcionamiento en el envío de transacciones de una base de datos principal a una base de datos espejo o secundaria.

Es posible montar Database Mirroring sobre SQL Server 2005 y SQL Server 2008. El hecho de poder montar el Servidor Principal sobre SQL Server 2005 y el Servidor Espejo sobre SQL Server 2008, permite plantearse soluciones de Database Mirroring interesantes para Migraciones de SQL Server 2005 a SQL Server 2008 con a penas corte de servicio y luego romper el Database Mirroring, si no lo queremos mantener.

Es importante tener en cuenta que NO es posible hacer funcionar Database Mirroring con el Servidor Principal en SQL Server 2008 y el Servidor Espejo en SQL Server 2005

Los posibles papeles o roles que puede desempeñar una instancia de SQL Server en una solución de Database Mirroring son:

• Servidor Principal. Mantiene la copia activa de la base de datos (base de datos principal), a través de la cual, se ofrece el servicio a los usuarios. Todas las transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos principal.

• Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base de datos espejo o mirror database), y aplica todas las transacciones enviadas por el Servidor Principal, manteniendo sincronizada la base de datos espejo.

• Servidor Testigo (Witness). Se trata de un elemento opcional. No es obligatorio o necesario implementar un Servidor Testigo (Witness) en una solución de Database Mirroring. Sin embargo, si deseamos que nuestra solución de Database Mirroring ofrezca recuperación automática ante fallos (automatic failover), entonces sí será necesario implementar un Servidor Testigo (Witness Server), pues éste es quién monitorizará los Servidores Principal y Espejo partícipes de una Sesión de Espejo (Mirror Session) con el objetivo de asignar el papel de Principal al servidor Espejo en caso de una caída de servicio o pérdida del primero (es decir, en caso de caída del Servidor Principal, se asignará el papel de Principal al Servidor Espejo, manteniéndose así el servicio). El trabajo realizado por el Servidor Testigo (Witness) no es muy intenso, por lo cual, no requiere de grandes recursos, y además, un mismo servidor puede actuar como Servidor Testigo (Witness) para múltiples sesiones de espejo, sin pérdida de rendimiento.

Database Mirroring ofrece tres modos de funcionamiento, como antes adelantamos:

• Modo de Alta Disponibilidad (síncrono y con testigo). Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Requiere de un Servidor Testigo (Witness) ubicado sobre una tercera máquina (que no sea ni el Servidor Principal ni el Servidor Espejo), gracias al cual es posible la recuperación automática ante fallos (automatic failover) o conmutación automática de roles. En caso de fallo del Servidor Principal durante el envío de transacciones, el Servidor Espejo tiene que terminar las transacciones encoladas antes de poder levantarse como Servidor Principal. Por supuesto también es posible la recuperación manual ante fallos (manual failover) o conmutación manual de roles. En caso de una caída o pérdida del Servidor Espejo, la base de datos principal se mantendrá activa.

• Modo de Alta Protección (síncrono y sin testigo). Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Sin embargo, no utiliza un Servidor Testigo (Witness). En este modo de funcionamiento, no es posible la existencia de pérdida de datos, pero la recuperación ante fallos se realiza de forma manual (manual failover). En caso de una caída o pérdida del Servidor Espejo, la base de datos principal dejará de estar activa, al haber perdido el Quorum.

• Modo de Alto Rendimiento (asíncrono y sin testigo). Las transacciones son aplicadas de forma asíncrona a la base de datos espejo, ofreciendo mejor rendimiento que los anteriores modos de funcionamiento, pero pagando como precio la existencia de posibles pérdidas de transacciones (y en consecuencia, potenciales pérdidas de datos). Evidentemente, la recuperación ante fallos se realiza de forma manual (manual failover), hablando de conmutación forzada (es decir, cambio de roles sin comprobación de datos escritos en el servidor espejo). En caso de una caída o pérdida del Servidor Espejo, el Servidor Principal no se verá afectado.

1. Primeramente preparamos nuestra base de datos espejo en nuestro server o instancia que fungirá como tal, aquí dos puntos importantes: Que la base datos que restauremos sea el ultimo backup realizado desde la principal. A la hora de restaurarla tenemos que marcar la opción de NON RECOVERY.



2. En el Management Studio, Explorador de Objetos, Seleccionamos una base de datos, hacemos click derecho sobre ella en la opción, Task, Mirror.

 
3. El primer paso sería configurar la seguridad, para lo cual vamos a seguir un asistente.


En el primer paso del asistente nos preguntara si queremos tener una instancia de testigo, para este primer ejempo le diremos que No.

4.       Luego definiremos el servidor principal

5.       Ahora definiremos nuestra instancia o servidor espejo

6.       En este paso se definen las cuentas de usuario que utilizaran tanto el servidor principal como el espejo que estén en un dominio. Para nuestro ejemplo dejaremos en blanco esta opción.

7.       Finalmente terminanos de configurar el asistente de seguridad.

8.       Una vez finalizado nos pedirá si deseamos iniciar el mirroring,  le diremos iniciar.

9.       Ya tendremos configurado nuestro mirroring como se muestra en la pantalla siguiente,  desde aquí podemos iniciar el mirroring,  y podemos configurar el tipo de operación que deseamos, tal y cual se planteo al inicio del articulo.  Hacemos click en OK.

La Redirección Automática del cliente en una infraestructura de Database Mirroring, es una funcionalidad muy apreciada, y en este caso, es tan fácil como utilizar una sintaxis determinada en la cadena de conexión a SQL Server, como se muestra en el siguiente:

"Data Source=PORTATIL;Failover Partner=PORTATIL\MIRROR;Initial Catalog=Demo;Integrated Security=True;"

Monitoreando el Performance en SQL Server

SQL Server Profiler

·         Muestra como SQL Server resuelve las queries internamente

·         Permite a los administradores ver como se ven las sentencias T-SQL  y como el servidor regresa los resultados.

·         Se puede:

o   Crear una traza basado en Templates

o   Verificar los resultados de la traza

o   Almacenar los resultados de la traza en un archivo o tabla

·         Capturar datos enviados al servidor que permite al programador verificar errores o datos incorrectos.

Windows System Monitor

·         Monitorear el uso de recursos.

·         System Monitor también llamado Performance Monitor.

·         Comparando SQL Server Profiler,  este monitorea eventos del motor de base de datos,  System Monitor monitorea el uso de recursos asociados con los procesos del servidor.

·         Se encuentra en el Panel de Control , Herramientas Administrativas, Monitor de rendimiento (en Español)   o bien Performance Monitor.

Activity Monitor

       Secciones:

1.       Vista General -  Muestra gráficamente el comportamiento del resto de secciones.

2.       Procesos – Muestra las actividades de los usuarios.  Que usuario esta impactando en que base.

3.       Recursos en Espera -  Espera el estado de la información. Que proceso está esperando un recurso.

4.       Data File  I/O -  Archivos de Data y Log  con información I/O

5.       Queries utilizadas -  Muestra las queries mas utilizadas recientemente.

Transact-SQL

·         sp_who 

·         sp_lock

·         sp_spaceused

·         sp_monitor

Windows Logs

·         Aplicación Externa a SQL Server

·         Podremos ver advertencias o errores ocurridos en los procesos de SQL Server.

·         Se encuentra en el Panel de Control , Herramientas Administrativas, Visor de Eventos(en Español)   o bien Events Log.

Default Trace

·         SQL Server “Caja Negra”

·         Para habilitarlo:

sp_configure 'default trace enabled', 1

RECONFIGURE

·         El trace que se creara por defecto será en la ruta donde esté instalado SQL Server. 

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log

·         Buscamos el archivo de traza  con extension .trc generado.