| ||||
Autor: Emilio Boucau - Microsoft MVP SQL Server Nota del autor: Las tres primeras slides corresponden a una breve introducción del SQL 2000 de 64 bits realizada por Gonzalo Moreno (Gerente de Servidores Microsoft - Argentina) Descargue la presentación técnica a la
que se refiere esta explicación:
(Slide #04) Son dos módulos los que integran esta presentación: Alta Disponibilidad de servidores SQL en la primera parte y optimización de Performance de SQL en la segunda. (Slide #05) El concepto de Alta Disponibilidad se sustenta en dos técnicas diferentes: el Failover Clustering y los Stand-by Servers o Warm Servers, mantenidos mediante el Log-Shipping. Cada una de estas técnicas responde a una metodología diferente y tiene un costo asociado diferente también. (Slide #06) Clustering … qué es Clustering ? En muchas ocasiones habremos oído hablar de Clusters o de Clustering, ya que es algo que se esta volviendo cada vez más popular en los entornos Windows (Slide #07) Volviendo un poco sobre la historia del soporte del Clustering en la platafora Windows, vemos que ya en los tiempos de NT 3.51 existía un add-on llamado Wolfpack o NT Cluster Plus Pack que habilitaba esto. Si bien no era todo lo estable y robusto que se necesitaba, era un comienzo muy prometedor. Posteriormente, se incluyó soporte nativo en NT 4.0 a través del MSCS (Microsoft Clustering Server), pero estaba disponible solamente en la versión Enterprise del producto. (Slide #08) El soporte brindado por SQL Server al Clustering data de los tiempos del SQL Server 6.5, que también soportaba ésto en la versión Enterprise. (Slide #09) La versión 7.0 trajo importantes cambios en el soporte del Clustering, ya que se apoyaba en una tecnología nativa en la plataforma sobre la que corría. Si bien no era una perfección, un Cluster sobre NT 4 / SQL 7 era una opción válida a ser considerada. (Slide #10) La actualidad del Clustering es muy diferente; esta muy evolucionado y se puede decir que es una solución confiable. En Windows 2000 se cambió el Cluster radicalmente, lo que llevó a un cambio de nombre también; ahora se llama MSCS (Microsoft Cluster Service). Esta disponible en las versiones Advanced y Datacenter de Windows 2000. Obviamente, todo sigue en desarrollo, pero implementar un Cluster sobre un Windows 2000 es algo relativamente sencillo y muy robusto. (Slide #11) Dependiendo del Cluster que se necesite montar será la plataforma que se habrá de seleccionar. Windows 2000 Advanced Server soporta Cluster de 2 nodos solamente; Windows 2000 Datacenter Server soporta Clusters de 3 o 4 nodos. (Slide #12) El Cluster más sencillo que se puede montar es de 2 nodos y pueden trabajar en modo Activo / Activo o Activo / Pasivo. Los Clusters de 3 y 4 nodos trabajan en forma similar y varios conceptos se aplican a ellos también. En un modelo de Cluster Activo / Pasivo hay un solo nodo funcionando a la vez, ya que el otro levantará ante la caída del primario. En un nodo Activo / Activo, cuando cae uno de ellos el otro toma control de esa instancia caída y ambas terminan corriendo en un único nodo. Tomando esto en consideración, el esquema Activo / Pasivo es el que ofrece un nivel de performance parejo ya que siempre es un solo nodo el que hace todo el trabajo, mientras que en un esquema Activo / Activo la performance merma con la caída de un nodo, pues antes había 2 servidores y ahora hay uno solo. (Slide #13) Cómo funciona un Cluster? Es una pregunta que se debe haber hecho casi todo el mundo cuando oyó hablar del concepto de Cluster. Un Cluster son 2 o más servidores (llamados Nodos) que trabajan unidos de forma tal que dan la impresión de ser un único server (llamado Server Virtual) y los clientes que se conectan no saben exactamente qué nodo les presta servicio en ese momento. Tampoco es relevante. Entre ellos hay un tramo privado de red llamado Heartbeat, que es el que mantiene informados a los nodos del estado de los demás nodos. Ante una falla de comunicación en el Heartbeat (indicando la caída de un nodo) el otro nodo entrará en proceso de Failover. En medio de estos nodos esta el array de discos compartido por ambos, que es que contiene las bases de datos. Dentro de este array se encuentra el Quorom Drive, que es un disco lógico que contiene información del estado del Cluster. Si este disco se corrompe, el Cluster se perderá. Recomendación: desactivar en las placas de red la capacidad de ‘sentir’ la red, pues cuando la placa está realizando esa tarea no presta servicio y se puede iniciar una respuesta de Failover no deseada del otro nodo. (Slide #14) Propiedades asignables al Servidor Virtual. (Slide #15) Pros del Clustering. (Slide #16) Contras del Clustering. (Slide #17) Software necesario para montar un Cluster de 2 nodos. (Slide #18) Software necesario para montar un Cluster de 3 o 4 nodos. (Slide #19) Hardware necesario para montar un Cluster. (Slide #20) Log-Shipping ... qué es Log-Shipping ? Básicamente descripto y en pocas palabras es realizar operaciones de RESTORE de archivos de Log de un servidor de producción en otro suplmentario para mantenerlo actualizado. Esto se puede hacer en forma automática o manual. (Slide #21) La activación del Log-Shipping forma parte del Plan de Mantenimiento de las bases de datos, pero se encuentra disponible de forma automática solamente en la versión Enterprise de SQL Server 2000. En SQL Server 7.0 esto venía incluído en el Resource Kit y era un grupo de scripts para implementarlo. (Slide #22) Los integrantes de un proceso de Log-Shipping son los siguientes: un servidor de producción al cual se le realizan operaciones de BACKUP del archivo de Log denominado Primario y uno o más servidores en los cuales se restauran esos archivos y se llaman Secundarios. Además, existe un tercer servidor que realiza el monitoreo de esta secuencia y se llama Monitor. Se pueden mantener varios servidores secundarios, pero al momento de suplantar el primario lo hará solo uno de ellos. Se pueden mantener varios por una razón de redundancia por si falla un secundario al tratar de ponerlo en línea. (Slide #23) Este slide muestra claramente cuál es la secuencia en un proceso automatizado de Log-Shipping. (Slide #24) Para poder configurar el proceso de Log-Shipping como automático deberá tenerse instalado SQL Server 2000 Enterprise Edition o SQL Server 7 y disponer del Resource Kit. Aquí se encuentra un juego de scripts que permiten esto. Es muy importante hacer al menos una vez un DTS que transfiera los Logins y Users de un servidor a otro de manera de evitar problemas de permisos. (Slide #25) Cuando se configure este proceso se deberán tener encuenta ciertos parámetros que nos afectarán a la hora de poner en línea un Stand-by Server. Estos factores son todos referentes a la frecuencia de actualización y el tiempo que tomará dejar el servidor operativo. (Slide #26) Estos son los pasos que se deberán seguir cuando se desee activar el Stand-by Server ante un desperfecto en el primario. (Slide #27) Supongamos un caso que se puede dar: No tengo SQL Server 2000 ni el RK del SQL 7 y quiero implementar Log-Shipping … qué hago ? (Slide #28) Para implementar un Log-Shipping manual se debrán utilizar las siguientes cláusulas de la instrucción RESTORE: WITH STANDBY / WITH NORECOVERY / WITH RECOVERY. (Slide #29) En el servidor de producción se deberá hacer un backup completo de la BBDD y luego realizar sucesivos backups del log a los intervalos que se desee. Habitualmente se progama un Job que haga esto. (Slide #30) En el servidor destino el proceso de RESTORE no es el habitual, ya que la sintaxis de RESTORE deberá ser acompañada por la cláusula WITH STANDBY para mantener el servidor en estado receptivo de más logs. Por otro lado, es perfectamente utilizable para procesos de lectura solamente. La cláusula WITH NORECOVERY también deja el servidor en estado receptivo pero no es accesible para consultas. Así se debe hacer con todos los archivos de Log que se deseen adosar. (Slide #31) En el caso de un problema en el servidor primario, se deberá hacer antes que nada y de ser posible, un último backup de Log y pasarlo al server destino. Al hacer el RESTORE del último Log deberemos hacer entrar la base en modo de recuperación especificando RESTORE DATABASE WITH RECOVERY. De esta forma, el servidor hará ROLLBACK y ROLLFORWARD de todas las operaciones que se encuentren en el log y llevará la BBDD a su estado final. Es importantísimo tener en mente el tiempo que insumirá el preoceso de recovery, ya que hasta que éste no termine no hay posibilidad de utilizar el servidor. Que se recomienda entonces ? Que cada cierto tiempo se haga el proceso de recovery aunque no sea necesario poner el servidor en línea aún, cosa de minimizar ese tiempo cuando realmente se lo necesite. (Slide #32) Estos son métodos para minimizar los tiempos muertos ante caídas de un servidor. Si bien son métodos probados y que funcionan, siempre deben ser vistos como un complemento y nunca reemplazar un esquema de seguridad que incluya un BACKUP de los datos. (Slide #33) Performance … para qué ? (Slide #34) Las premisas sobre las que se fundamenta todo análisis de la performance son las siguientes: El tiempo es dinero, por lo que cualquier demora solo aumenta los costos de lo que se este procesando. Es muy cierto que a ninguno de nosotros nos gusta esperar, sobre todo, cuando esos tiempos se pueden reducir. Aprovechar al máximo la plataforma disponible es la forma de darle el erdadero valor a la inversión realizada. (Slide #35) Cuando se necesite determinar la causa de una merma en la performance, se debería seguir esta secuencia: primero, revisar a fondo el front-end. Luego, el diseño de la base de datos (el uso excesivo de triggers puede enlentecer la operatoria, por ejemplo). En tercer lugar, la configuración actual del SQL Server y finalmente, el hardware actual. El hardware puede estar mal dimensionado o ser insuficiente debido a que las operaciones actuales sobrepasan el dimensionamiento original. (Slide #36) En toda consulta solo se deben recuperar las columnas deseadas y siempre (hay muy pocos casos que no lo requieren) usar la cláusula WHERE. (Slide #37) Es primordial tener definidos los índices adecuados para los procesos. Algo a tener en cuenta para reducir tiempos es el uso de los Cover Indexes. Un Cover Index incluye como parte de su estructura la columna que se desea recuperar. Por ejemplo, en un banco se puede definir un índice que sea el ID del cliente y el saldo actual. Si bien nunca habrá dos o más IDs iguales con lo cual incluír el saldo no hará diferencia al ordenar), el hecho de tener ese valor disponible evitara ir a buscarlo a la tabla. Cuando se consulte por un ID en particular, el valor del saldo ya estará disponible. Siempre que sea posible, convertir en Stored Procedures las consultas o procesos que sean repetitivos. Esto se recomienda ya que existe una serie de pasos que se deben llevar a cabo antes de la ejecuión de un script y estos pasos se pueden guardar, con lo cual son reutilizables y se ahorra tiempo. A su vez, es de extrema importancia analizar el plan de ejecución de una consulta. Que una consulta devuelva lo que se necesita es la mitad de la tarea, deberá hacerlo de la mejor manera también. (Slide #38) Cuando una consulta se ejecuta se llevan a cabo varios pasos: primero SQL Server realiza un control de sintaxis. Si ésta es correcta, se da paso a una standarización de la sentencia. Luego se hace una optimización de la misma y para el final quedan la compilación y la ejecución. En el proceso de optimización, SQL Server busca lo que se denomina ‘Argumentos de búsqueda’, que son las partes de las cuales se puede valer SQL Server para decidir cuál es el método adecuado de resolución de esa consulta. Se consideran pertenecientes a este grupo los operadores =, >, <, <=, >=, BETWEEN, LIKE e IN. A la larga estos últimos se transforman en operadores del tipo anteriormente mencionado; es decir, una instrucción IN se descompone en algo asi: Campo = Valor_A OR Campo = Valor_B. Como se ve, los operadores lógicos AND y OR apoyan todo esto. Es de esperarse entonces que los índices esten definidos acorde a las consultas que se deberan procesar, de forma tal que el optimizador se apoye en ellos. A su vez, utiliza las estadísticas cuando no tiene un índice por alguna columna que necesita. (Slide #39) No se consideran argumentos de búsqueda válidos a las las comparaciones entre columnas u operaciones sobre ellas, pues la única forma de obtener el resultado de eso es realizar la operación (cosa que no esta almacenada en un índice o en una estadística). (Slide #40) El optimizador sale a la caza de los JOINs cuando realiza su tarea, ya que si los mismos estan correctamente escritos, le permitirán utilizar todo lo antes mencionado. Microsoft recomienda no utilizar la cláusula WHERE para plantear la condición del JOIN, sino utilizar ON. Cuál es la diferencia ? Que cuando se utiliza ON para hacer la concordancia de columnas se deja la cláusula WHERE para especificar las condiciones que deberán cumplir las filas una vez unidas las tabla, y aquí si se pueden emplear los índices. (Slide #41) En el ejemplo, se ve la misma consulta escrita de dos formas diferentes: el estilo que acepta el T-SQL y la norma ANSI. Se recomienda que se use la norma ANSI, aunque sea un poquito mas larga de escribir, ya que de esta forma se hace una concordancia explícita de las columnas y se aprovechan los índices. (Slide #42) Es muy importante encapsular el código dentro de Stored Procedures, ya que los mismos permiten aprovechar toda la potencia del servidor. Cada vez que se ejecute ese Stored Procedure, el código ya estará controlado, standarizado, optimizado y compilado, con lo cual solo quedará su ejecución. En caso de hacer cambios en la estructura de la base que puedan impactar sobre el plan de ejecución de un Stored Procedure (agregar un índice sobre una columna, por ejemplo) se recomiendo utilizar sp_recompile para hacerle saber a SQL Server que la próxima vez que ese Stored Procedure se ejecute, debe ser recompilado y un nuevo plan de ejecución debe ser creado. De lo contrario, usará el existente y el índice creado no hará ninguna diferencia. (Slide #43) Si bien los triggers son un poderoso aliado, se pueden convertir en focos de merma de performance, ya que son código adicional a ejecutar en un evento dado, y no están a la vista en el momento de desarrollar o analizar una consulta. Tanto los triggers AFTER como los INSTEAD OF deben ser tenidos bajo control. Evitar a toda costa el uso de cursores ! Hay contados casos que sólo se resuelven con cursores y es importante no caer en ellos. Por otro lado, utilizar la tecnología de OLEDB para acceder los datos, ya que es lo más rápido con que contamos hoy en día. (Slide #44) Las herramientas que se tienen el control de la perfomance son: SQL Server Profiler y Windows Performance / System Monitor. Es primordial que se delinee un comportamiento base del servidor, medido en diferentes momentos y con diferentes niveles de carga, para luego poder comparar las muestras que se tomen en producción. Este tema es muy amplio de abarcar, pero confeccionar una línea de base no es tan difícil. (Slide #45) Para finalizar, es muy importante que si se tienen servidores de misión crítica se refuerce la disponibilidad mediante el uso de un cluster o el log-shipping automático / manual. Nunca se deberá descartar la política de backup, independientemente de la redundancia que se tenga. Siempre se tiene que monitorear el comportamiento y la performance del servidor. No solo cuando hay problemas, sino para prevenirlos también. | |||
