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

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

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.

Clonando servidores a través de los discos.

Que tal,

Tal vez alguna vez han estado en una situación en la que se necesita "clonar servidores", pero no se tiene una herramienta como Altiris, Ghost, etc, si los servidores son del mismo modelo, mismos discos (velocidad, capacidad, etc) y misma tarjeta controladora PERC es posible hacer un clonado de los discos sin instalar nada y se tienen servidores identicos.

Esto lo acabo de hacer con servidores Dell con RAID 1, controladora PERC, 2 discos en espejo.

Aqui van los pasos:

1. Sacar del dominio (en caso de estar en alguno) al servidor, de preferencia tener instalado el OpenManage Server Administrator.
2. Apagar el servidor y sacarle uno de los discos.
3. Al nuevo servidor apagarlo tambien y sacarle uno de los discos, de preferencia del mismo lado.
4. Encender el equipo y entrar a la controladora de la PERC (Ctrl+M), navegar en la configuracion hasta la parte donde vienen los discos duros y marcar el disco original (no el que le acabamos de poner) como offline, lo que hará esto, es marcar el disco como degradado y ya no lo tomará en cuenta para bootear ni nada.
5. Reiniciar el equipo, al iniciar entrar al Server Administrator, navegar hasta el disco marcado como degradado y forzar un rebuild, con esto se empezará a reconstruir el disco que ya tenia el servidor con la nueva información.
6. Ahora, con el disco que habiamos sacado del servidor, meterselo de nuevo al servidor y hacer el mismo procedimiento, encender el servidor, entrar a la controladora, marcar el disco que acabamos de poner como degragado y encender el equipo.
7. Entrar al OpenManage Server Administrator y forzar un rebuild.


Con esto se tienen 2 servidores iguales, sin hacer nada de configuracion, puede sonar un poco complicado y riesgoso, pero es muy efectivo.