Friday, February 26, 2010

Book Review: Pro SQL Server 2008 Failover Clustering

 

Pro SQL Server 2008 Failover Clustering, by Alan Hirt is over 370 pages about installing, configuring and tuning your SQL Server 2008 failover cluster. This book is a must read for everyone interested in migrating SQL 2005 in a failover cluster to SQL 2008 on Windows 2008 or anyone who just want to know some basic aspects about clustering in Windows 2008, some concepts also work for SQL 2005.

The book cover the following topics:

  • Failover Clustering Basics
  • Preparing to Cluster Windows
  • Clustering Windows Server 2008 Part 1: Preparing Windows
  • Clustering Windows Server 2008 Part 2: Clustering Windows
  • Preparing to Cluster SQL Server 2008
  • Installing a New SQL Server 2008 Failover Clustering Instance
  • Upgrading to SQL Server 2008 Failover Clustering
  • Administering a SQL Server 2008 Failover Cluster
  • Virtualization and Failover Clustering.

I’m right now following chapter by chapter the entire book to configure my SQL Server 2008 on my Windows 2008 cluster. What I liked the most about this book is that it teachs you how to configure anything using GUI, commands and PowerShell.

Failover Clustering Basics:

This chapter talks about some very basic aspects of clustering, before you actually even touch the server, the things you must know.

Preparing to Cluster Windows
This chapter starts explaining the concepts about clustering in Windows 2008, how to create them, quorum configuration, about the changes about the account that runs the cluster.

Clustering Windows Server 2008 Part 1: Preparing Windows

This chapter talks about networking (I think I should have talked about disabling TCP Offload, RSS, TCPA, etc), windows 2008 features to enable and expand more about the special account that runs the cluster.

Clustering Windows Server 2008 Part 2: Clustering Windows

It explains about the validations you should run in your cluster, before installing anything, quorum configurations.

Preparing to Cluster SQL Server 2008

This chapter starts talking about SQL 2008,  what is clusterable and what not and some considerations you should be aware and what they entail.

Installing a New SQL Server 2008 Failover Clustering Instance

This chapter talks about the installation steps in SQL 2008, it guides step by step toward the end and it is very useful, you can follow easily these steps and configure your cluster in minutes.

Upgrading to SQL Server 2008 Failover Clustering

This talks about some considerations you should be aware if you are migrating from SQL 2000 or SQL 2005, very helpful, there other books that covers this more deeply though.

Administering a SQL Server 2008 Failover Cluster

This chapter talks about some related things you may be into, after you have your cluster up and running, like adding disks, nodes, changing ips, etc

To sum up, I deeply recommend this book to anyone involved in installing and migrating SQL servers to SQL 2008

Thursday, August 20, 2009

Obteniendo las tablas con mas registros.

Que tal,

Recientemente estaba tratando de ver las tablas que mas consumían espacio en todas las bases de datos, encontré un script en un blog que mostraba el total de registros en la base de datos, pero yo quería que fuera para todas las bases de datos.

Así que le hice unos pequeños cambios para que funcionara con todas las bases de datos.

Les comparto el script, esta probado en SQL 2005 aunque debería funcionar en SQL 2008.

El script no hace un count(*) a todas las tablas, sino que va directamente a las tablas de sistema:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[BPSQL_Select_big_tables]
AS
BEGIN
SET NOCOUNT ON;

DECLARE @dbname2 varchar(40);
declare @id varchar(30);

DECLARE dbname CURSOR FOR select name,database_id from master.sys.databases where database_id>4

create table #tablas(
base_de_datos varchar(128),
tabla varchar(128),
total int
)

OPEN dbname
FETCH NEXT FROM dbname
INTO @dbname2,@id

WHILE @@FETCH_STATUS = 0
BEGIN

exec('SET NOCOUNT ON
use [' + @dbname2 + ']
insert #tablas

SELECT b.name,OBJECT_NAME(object_id) AS [Table Name], SUM(Rows) AS [Row Count]
FROM sys.partitions,sys.databases b
WHERE index_id < 2
and OBJECT_NAME(object_id) not like ''%sys%'' and OBJECT_NAME(object_id) not like ''%queue%''
and OBJECT_NAME(object_id) <> ''dtproperties'' and b.database_id='+@id+'
GROUP BY object_id,b.name
ORDER BY SUM(Rows) DESC')

FETCH NEXT FROM dbname INTO @dbname2,@id
END

CLOSE dbname
DEALLOCATE dbname

select top 100 *
from #tablas
order by 3 desc
drop table #tablas

END

Tuesday, July 28, 2009

Revisando si existen permisos directos a los usuarios.

Una de las best practices en la administración de bases de datos, es asignar los permisos solo a los roles y no a los users o grupos, esto hace que las migraciones, planes de DRP, etc sean más sencillas.

Una de las formas de asegurar que se cumple con esta política en SQL 2005 es correr un script que indique si existen permisos directos a los users o grupos, en lugar de los roles.

Les comparto un script que hice, en el que se revisan en todas las bases de datos del servidor si se asignaron permisos directos, en caso de ser así, regresará la base de datos, el user, el tipo de permiso y la tabla, SP, etc.

Espero les sirva, yo lo corro diariamente en todos los servidores.


/* Revisa si existen usarios que tengan permisos directos en cada base de datos */
DECLARE @dbname2 varchar(40);
declare @id varchar(30);

DECLARE dbname CURSOR FOR select name,database_id from master.sys.databases;

CREATE TABLE #Permisos_Users(
[base_de_datos] [varchar](128) NULL,
[usuario] [varchar](128) NULL,
[tipo_permiso] [varchar](128) NULL,
[objeto] [varchar](128) NULL
)

OPEN dbname
FETCH NEXT FROM dbname
INTO @dbname2,@id

WHILE @@FETCH_STATUS = 0
BEGIN
exec('SET NOCOUNT ON;
use [' + @dbname2 + ']
INSERT #Permisos_Users
select d.name,b.name,a.permission_name,c.name from sys.database_permissions a inner join sys.database_principals b on a.grantee_principal_id=b.principal_id
inner join sys.objects c on a.major_id=c.object_id,sys.databases d where b.type_desc in (''SQL_USER'',''WINDOWS_USER'',''WINDOWS_GROUP'') and b.default_schema_name is not null
and b.name <> ''dbo'' and b.name <> ''guest'' and a.permission_name <> ''CONNECT'' and convert(varchar,d.database_id)='+@id+'')

FETCH NEXT FROM dbname INTO @dbname2,@id
END

CLOSE dbname
DEALLOCATE dbname

select * from #Permisos_Users

drop table #Permisos_Users

Friday, July 17, 2009

Planes de mantenimiento en SQL

Muchas veces me he topado, que en diferentes empresas tienen planes de mantenimiento de SQL en el que, por ejemplo, una vez a la semana hacen un reorganize, rebuild y despues un "Update Statistics" a todas las bases de datos operativas.

Lo he visto configurado así y me sorprendo que así lo tengan, es común verlo en las que el DBA está por accidente.

Este tipo de mantenimientos no deberían de estar al mismo tiempo, ya que es redundante, es un desperdicio de recursos y en ocasiones hasta puede salir contraproducente.

Lo que idealmente debería pasar es estar monitoreando el nivel de fragmentacion de los indices, si los indices tienen menos de un 30% de fragmentacion, entonces aplicaría un reorganize y si es mas alto entonces un rebuild, un rebuild es mucho mas costoso en performance pero es más efectivo, si se tiene la versión Enterprise de SQL 2005, se puede hacer Online y de esta manera no se afecta a los usuarios, excepto aquellas tablas que tengan columnas LOB, idealmente se debería hacer sobre demanda en las tablas que lo necesiten.

Esto es idealmente, si tienes una base de datos en las que se hacen muchos cambios (INSERT, DELETE, UPDATE) entonces lo recomendable es que se haga solamente un rebuild, en el momento mas oportuno, cuando no afecte la operación, si tienes la versión Enterprise de SQL 2005/2008 entonces se puede hacer Online.

Tambien se podría hacer un reorganize O un update statistics diario y aunque no son tan efectivos como el rebuild tambien ayudan a mejorar el performance y no tienen afectación a los usuarios.

Voy a estar compartiendo mas informacion sobre este tema más adelante.

Apuntes sobre Tomcat en Windows.

Recientemente estuve trabajando con Tomcat corriendo sobre Windows y después de estar trabajando con el por unos días tengo algunos tips que les pueden ser útiles.

Las versiones que utilizé fueron Tomcat 6.0.16 con Java 6 Update 7, pero podrían aplicar sobre otras versiones.

Aqui van algunos tips:

En el server.xml modificar la parte de logueo, ya que por default está deshabilitado y configurarlo para que no haga un resolve:

Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="combined" resolveHosts="false"


Si se van a tener contextos en los que constantemente se van a estar actualizando las aplicaciones, en produccion, por ejemplo, entonces hay que cambiar el archivo context.xml con las opciones antiResourceLocking="true" antiJARLocking="true" reloadable="true", modificarlo de:

Context

a

Context path="" antiResourceLocking="true" antiJARLocking="true" reloadable="true" cachingAllowed="false"


Al hacer esto todas las aplicaciones se copiarán al folder temp y desde ahí se van a servir y automaticamente se hara un deploy en caso de ser necesario. Esto es necesario porque en Windows los archivos se queden "lockeados" y las aplicaciones no se "recargan" completamente.


Si se configura de esta manera y tambien se tienen archivos estáticos, hay que configurar el contexto en el server.xml para excluirlo, de otra manera el contenido nuevo nunca se va a mostrar (a menos que se esté reiniciando el servicio de Tomcat).

Así quedaría:

Context path="/mifolder" antiResourceLocking="false" antiJARLocking="false" reloadable="false" override="true"



Tambien es recomendable configurar la memoria RAM que puede utilizar el tomcat, desde el archivo tomcatw.exe (en el folder bin), aquí se puede configurar la RAM mínima y máxima que puede utilizar el Tomcat.


Espero les sirvan estos tips.