Migrando de cluster Windows 2003 R2 + SQL Server 2005 a cluster Windows 2008 R2 + SQL Server 2008 R2

SQL Server

http://blogs.solidq.com/es/sql-server/migrando-de-cluster-windows-2003-r2-sql-server-2005-a-cluster-windows-2008-r2-sql-server-2008-r2/x

Uno de los problemas con los que nos encontramos en ocasiones durante los upgrades de versión de SQL Server es que se solapan con upgrades de sistema operativo. Si a esto sumamos que estas instancias y operativos pueden estar trabajando en cluster la situación se complica siendo preciso seguir cuidadosos pasos para poder llevar a cabo la migración en un modo digamos “pseudo in-place”.En este post vamos a mostrar una de las formas en las que podríamos migrar una instancia SQL Server 2005 SP3 Enterprise Edition, que se encuentra sobre un nodo de un cluster Windows Server 2003 x64 R2 SP2 , a una instancia SQL Server 2008 x64 R2 SP1 Enterprise Edition. Durante la migración no se utilizará hardware adicional por lo que aunque no se trata de una migración “in-place” tradicional sí podemos verla como tal desde el punto de vista de los recursos necesarios.

 Vamos a familiarizarnos con el entorno inicial con el que contamos y que está compuesto por 4 máquinas virtuales (un controlador de dominio, un servidor que nos proporciona los discos compartidos por iSCSI y dos nodos Windows 2003 en cluster donde está instalada una instancia de SQL Server 2005):



Los dos nodos tendrán acceso directo a los mismos discos (Quorum + Disco Datos Instancia):




La configuración del cluster es una de las más típicas en estos escenarios, un cluster de 2 nodos activo/pasivo con un Quorum basado en disco compartido:



Debido a que el sistema operativo actual, Windows Server 2003 R2 SP2, está soportado por SQL Server 2008 R2 hemos elegido comenzar  actualizando la actual instancia de SQL Server 2005 a SQL Server 2008 R2. Para ello comenzaremos instalando los requisitos en cada uno de los nodos y que no se

Replicación transaccional en SQL Server: Una historia de publicadores, suscriptores y agentes.

SQL Server

http://blogs.solidq.com/es/sql-server/replicacion-transaccional-en-sql-server-una-historia-de-publicadores-suscriptores-y-agentes/

SQL Server dispone de múltiples tipos de replicación de datos que nos ayudarán a automatizar la duplicación de datos. Habitualmente estos datos son duplicados para sacar un beneficio de ello. Un ejemplo típico es el desacoplamiento de cargas de lectura y de escritura, donde desde una instancia de lectura/escritura distribuimos datos a N servidores de solo lectura. Otro escenario típico de replicación implica la duplicación de datos entre una oficina central y un conjunto de oficinas distribuidas geográficamente.

En este post vamos a mostrar paso a paso cómo configurar una replicación transaccional unidireccional explicando durante el proceso de configuración los roles implicados así como los distintos agentes. El primer paso que debemos realizar es configurar la distribución de datos en nuestro publicador. El servidor publicador será aquel servidor (central, principal, etc.) que contendrá los datos que deseamos replicar a los servidores suscriptores (secundarios, oficinas, etc.). Para configurar la distribución utilizaremos la opción “Configure Distribution…” directamente desde Management Studio:

Indicaremos que el distribuidor de nuestra instancia será la misma instancia que estamos utilizando para publicar los datos:

Esta configuración es válida cuando la carga de nuestra réplica no es elevada, el número de suscriptores no es muy alto y no tenemos funcionalidades de alta disponibilidad no compatibles con el rol de distribución. Por ejemplo podemos tener esta configuración sin problemas montada en un cluster pero si utilizamos

Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group

SQL Server

http://blogs.technet.com/b/canitpro/archive/2013/08/20/step-by-step-creating-a-sql-server-2012-alwayson-availability-group.aspx

One of the most talked about (and now frequently requested) feature in SQL Server 2012 isAlwaysOn Availability Groups. It brings SQL Server high availability and disaster recovery to a whole new level by allowing multiple copies of the database be highly available and potentially using them for read-only workloads and offloading management tasks such as backups. AlwaysOn Availability Groups allow you to fail over a group of databases as a single entity, unlike database mirroring where you can only do so one database at a time. This is very useful for applications that access multiple databases in a single SQL Server instance like SharePoint Server 2013. In fact, very recently, one of my customers had requested to configure SQL Server 2012 AlwaysOn Availability Groups for their SharePoint 2013 farm. I am also seeing more and more SharePoint 2013 farms leveraging on the SQL Server 2012 AlwaysOn Availability Groups for both high availability and disaster recovery. 

This step-by-step has been created to help you get started in creating a SQL Server 2012 AlwaysOn Availability Group for your mission-critical databases.

Prerequisites

• Windows Server Failover Cluster (WSFC). AlwaysOn Availability Groups rely on the Windows Server Failover Cluster for failure detection and management of the Availability Group replicas. This is where a lot of customers get confused because of their previous knowledge of Microsoft Cluster Services (MSCS.) In previous versions of Windows Server, you need shared storage to create a failover cluster for the quorum disk. Windows Server 2008 and higher provided the option to use a file share witness as a quorum configuration. Therefore, you DO NOT need shared storage to create a Windows Server Failover Cluster for AlwaysOn Availability Groups. This, of course, does not change the requirement if you intend to use a SQL Server Failover Clustered Instance (FCI) as a replica in your Availability Group. For this step-by-step, we will only be working with standalone SQL Server 2012 default instances.
• Download SQL Server 2012 Enterprise Edition. AlwaysOn Availability Group is an Enterprise Edition feature. Before deciding to implement this feature, take stock of your SQL Server licenses to make sure you have enough to get you covered. If you intend to use the other replicas for read-only workloads or offloading your backups, you would need licenses for those SQL Server instances as well. This is also another one of those items that customers get confused with because in previous versions of SQL Server, database mirroring can be configured with Standard Edition. 
• Same SQL Server collation for all replicas. I usually don’t recommend running databases with different collation requirements in the same SQL Server instance due to potential issues caused by applications using temporary tables. This is one of the reasons for keeping the database collation the same for a single instance (SharePoint 2013 also requires a specific collation for the content databases.) If you want to configure AlwaysOn Availability Groups for your databases, they should all be running the same collation on all of the SQL Server instances acting as replicas.
• Two to Five SQL Server Instances acting as replicas. SQL Server instances that will be used as a standby for high availability and/or disaster recovery are called replicas. Unlike database mirroring where you can only have one extra copy of the database, AlwaysOn Availability Groups allow you to have up to five copies of the database running on five replicas – three of which can be configured for synchronous-commit mode and two in asynchronous-commit mode.
  

Calculando un grado de paralelismo “razonable”

SQL Server

http://blogs.solidq.com/es/sql-server/calculando-un-grado-de-paralelismo-razonable/

Un parámetro de configuración que genera habitualmente discusiones de lo más controvertidas es el grado máximo de paralelismo (max degree of parallelism). En este artículo vamos a ver las recomendaciones generales y también una aproximación a cómo podemos calcular este valor de una forma más empírica para nuestras consultas.

Para sistemas con la carga más típica que nos solemos encontrar (mayor parte de OLTP y algunas consultas analíticas) las recomendaciones generales son un buen punto de partida:

• En sistemas NUMA, no configurar un grado de paralelismo mayor que el número de cores físicos por nodo NUMA.
• No configurar el grado de paralelismo máximo por encima de 8.

También es importante que en el caso que nuestra instancia vaya a ser utilizada por software de terceros revisemos las recomendaciones del fabricante al respecto. Por poner un ejemplo habitual, Dynamics AX recomienda un grado de paralelismo 1. Al tratarse de un parámetro a nivel de instancia y no de base de datos deberemos buscar un valor de compromiso pensando en todas las aplicaciones que vayamos a ejecutar. En casos extremos tendremos que aislar en instancias independientes las distintas aplicaciones o, si disponemos de Enterprise Edition, podremos utilizar Resource Governor para controlar este parámetro. También es importante revisar el algoritmo utilizado por SQL Server para obtener el valor de paralelismo a utilizar que podemos encontrar en el siempre interesante blog de CSS SQL Escalation Services:

http://blogs.msdn.com/b/psssql/archive/2013/09/27/how-it-works-maximizing-max-degree-of-parallelism-maxdop.aspx

Contadores de Memoria de un Servidor

Windows Server

http://blogs.msmvps.com/pmackay/2007/12/08/post27/

Contadores

Los contadores son entidades u objetos que mantienen información del funcionamiento de algún programa o sistema operativo. Cada programa que utilizas –todos debieran, pero no siempre lo hacen– genera información con estadística y en tiempo real del funcionamiento de éste, la cual se le informa al SO. A su vez, el SO también genera información que almacena para que nosotros podamos consultarla y saber cómo está funcionando.

Los contadores se categorizan por objetos (por ejemplo, memoria, sistema, sql server, iis) y se pueden o no aplicar a instancias (procesos, sitios web, bases de datos, etc.)

Por ejemplo, un contador de importante SO es la cantidad de memoria disponible que le queda. Este se categoriza en el objetoMemory, y el contador se llama Available MBytes, que nos dice la cantidad de megabytes de memoria disponible. Los nombres de los contadores dependen del idioma del programa o SO. Si estás ejecutando un SO en español, el objeto podría llamarse Memoria y el contador, cantidad de MB disponibles.

Luego, después de habar agregado los contadores, podrás ver una pantalla como ésta, donde la primera es la representación gráfica y la otra la textual, para la misma información.

/3GB -> Memoria de Kernel

Windows Server

http://blogs.msmvps.com/pmackay/2007/06/24/post12/

Escenario

• Failed to create a desktop due to desktop heap exhaustion
• Event ID 2019: “The server was unable to allocate from the system nonpaged pool because the pool was empty.”

En una arquitectura de 32 bits, la memoria virtual es un recurso medianamente escaso. No vamos a hablar de la cantidad memoria física del servidor. Si bien, mientras más memoria mejor, el problema a describir ahora no depende totalmente de la cantidad de memoria del servidor, ya que o bien tengas 2 o 20 GB, se presentará igual.

Con 32 bits, la memoria virtual, que tampoco tiene que ver con la memoria paginada en disco, está restringida a 4GB por aplicación. El valor 4GB se obtiene al elevar 2 a 32, o 2^32.

De esos 4 GB virtuales, 2 GB son usados por un proceso y los otros 2 por el kernel. Cada aplicación tendrá sus 2 GB virtuales y compartirán los 2 GB de kernel. Debido a esto último, algunos de ustedes recordarán haber visto en Task manager que un proceso nunca pasa de 1,7 o 1,8 GB. Bueno, la explicación es esa. Una aplicación no puede usar más de 2 GB de memoria virtual.

Existe un switch para que sí lo haga, pero con su consecuencia. Este switch se configura en el archivo boot.ini, y corresponde a la opción /3GB.

El impacto de la aplicación de éste es que del espacio virtual de 4 GB, 1 GB pasa de memoria de kernel a memoria de proceso de usuario. Entonces ahora un proceso de usuario puede llegar a usar 3 GB y el kernel queda drásticamente reducido a 1 GB.

Controlar el tiempo que lleva una aplicación activa con Powershell

Powershell

http://rlbisbe.net/2013/01/31/controlar-el-tiempo-que-lleva-una-aplicacion-activa-con-powershell/

Powershell es una herramienta muy versátil para desarrolladores y administradores de sistema, ya que, al igual que la shell de unix, permite automatizar tareas repetitivas con facilidad. Una de estas tareas puede ser controlar un proceso, aplicación o programa, cuanto tiempo lleva activo, y el uso de recursos que está haciendo.

En este artículo se verá cómo obtener el tiempo de un proceso en Powershell, el uso de CPU y RAM, así como enviar un e-mail con esa información de manera periódica.

Obteniendo la información del programa

Powershell recopila toda la información posible de un programa en el comando:

Get-Process Nombre_del_ejecutable (por ejemplo iexplore)

Este comando devuelve toda la información del mismo, desde la fecha de inicio, hasta los consumos actuales de CPU o RAM.