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.