SQL Server, ideas y experiencias

Como recuperar la contraseña del SA si se perdió o se olvidó

por Jose Mariano Alvarez 25. febrero 2011

PanicoComo los instaladores del SQL Server de las últimas versiones, no incorporan automáticamente al grupo de administradores de Windows (builtin\Administrators) como administradores del SQL Server (y tampoco es una buena práctica hacerlo), es bastante probable que ocurran este tipo de problemas o accidentes si los procedimientos para la generación, protección y guardado de contraseñas no están documentados y no son estrictos.

A veces, durante los procesos de operación y administración de los servidores, o instalación y configuración, puede suceder que se pierden las contraseñas o los privilegios de los administradores de un motor de base de datos de SQL Server. Entre los casos más habituales se encuentran por ejemplo:

  • Se han quitado todos los inicios de sesión o todos los grupos de Windows que son miembros del rol fijo de servidor sysadmin,
  • Los inicios de sesión que son miembros del rol fijo de servidor sysadmin son personas que no están disponibles porque han dejado la empresa o están de vacaciones por ejemplo
  • Se pierde la contraseña, ya sea del SA o de un inicio de sesión creado como administrador de SQL Server.

Una manera de solucionar este problema es reinstalar SQL Server. Sin embargo este procedimiento tiene algunas consecuencias ya que más allá del tiempo necesario para realizar la reinstalación se pierden en este proceso datos que están grabados en las bases del sistema, como por ejemplo los inicios de sesión (o logins) y por lo tanto se deberá recuperar estos datos desde una copia de seguridad. Se debe tener en cuenta que al realizar este proceso de restauración se vuelve al estado anterior al proceso de instalación porque se reescribe la base de datos del sistema con una copia previa y dependiendo del caso, podría tener los mismos inicios de sesión que antes de la reinstalación y por consiguiente, los administradores aún no tendrán acceso.

Solución

Para resolver este problema, lo mejor es aprovechar las propiedades que tienen los administradores de Windows luego de iniciar la instancia de SQL Server en modo de usuario único utilizando la opción -m. Después de iniciar la instancia del SQL Server en modo de usuario único, cualquier miembro del grupo local de administradores del equipo puede conectarse a la instancia de SQL Server como miembro del rol fijo de servidor sysadmin y realizar tareas administrativas como cambiar permisos. Se debe tener en cuenta que en este modo no se pueden realizar todos los cambios posibles. Esto previene que los administradores de Windows abusen de los privilegios de actuar como un administrador de SQL Server.

Los pasos a seguir son los siguientes:

  1. Abrir el SQL Server Configuration Manager desde el menú de Windows y detener el servicio de la instancia del SQL Server involucrada.
  2. En la solapa de “Avanzado” (Advanced), en el cuadro de texto propiedades (Properties), agregar “;–m” al final de la lista en la opción de parámetros de arranque “Startup parameters”. Debe tenerse en cuenta que no haya espacios entre “;” y “-m” porque si no va a dar error.
  3. Aceptar los cambios presionando “OK”.
  4. Reiniciar la instancia del SQL Server. En este instante se debe verificar que el resto de los servicios que componen el SQL Server están de detenidos, especialmente si alguno de esos corre con una cuenta de servicio que es administrador local, porque estos servicios podrían conectarse utilizando la única conexión disponible antes de que lográramos conectarnos para realizar los cambios necesarios, y ya no sería posible que nos conectáramos porque sería una segunda conexión.
  5. Conectarse al sql server utilizando autenticación Windows mediante la herramienta de línea de comandos “sqlcmd”. El usuario de Windows debe ser administrador local. (*)

    Por ejemplo:

    SQLCMD –S Localhost –E
  6. Ejecutar por ejemplo un comando TSQL como "sp_addsrvrolemember" para agregar un inicio de sesión existente (o uno nuevo recién creado con CREATE LOGIN) como administrador del sql server o cambiar la contraseña de inicio de sesión con ALTER LOGIN.

    Por ejemplo:
    CREATE LOGIN [Dominio\usuario] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
    GO
    EXEC master..sp_addsrvrolemember             
    @loginame = N'Dominio\usuario',
    @rolename = N'sysadmin' GO
  7. Luego de que se tiene acceso al sql server como administrador, eliminar el “;-m” como parámetro de arranque utilizando el configuration manager y reiniciar la instancia del sql server.

(*) Importante: Si el sistema operativo tiene User Account Control (UAC), y está activado,  a pesar de pertenecer al grupo de administradores locales, no es posible conectarse al SQL Server con privilegios de administrador local a menos que la consola se abra con la opción de “ejecutar como administrador” utilizando el menú de contesto que aparece presionando el botón derecho sobre el icono del CMD.EXE.

Referencias:

Solucionar problemas: conectarse a SQL Server cuando los administradores del sistema no tienen acceso

http://msdn.microsoft.com/es-ar/library/dd207004.aspx

Iniciar SQL Server en modo de usuario único

http://msdn.microsoft.com/es-ar/library/ms188236.aspx

Tags: ,

Artículos

FIX para el Error 315 The backup set holds backup of a database other than the existing database

por Jose Mariano Alvarez 25. noviembre 2010

Hace poco migrando de equipo y edición (pero no de versión) una base de datos de SQL Server utilizada por Blackberry que estaba en un SQL Server 2005 SP3 me dio un error al realizar un RESTORE con el siguiente comando en el nuevo servidor:


RESTORE
DATABASE [BESMgmt] FROM DISK = N'O:\MSSQL\Blackberry\BESMgmt20101125.bak' WITH MOVE N'BESMgmt_data' TO N'O:\MSSQL\Blackberry\BESMgmt.mdf', MOVE N'BESMgmt_log' TO N'O:\MSSQL\Blackberry\BESMgmt.ldf', NOUNLOAD, STATS = 10 GO

El error fue el siguiente

Error 3154: The backup set holds a backup of a database other than the existing database.

Lo extraño fue que había hecho el Backup con el siguiente comando con lo cual estaba totalmente seguro que el archivo de Backup contenía la base de datos correcta.

BACKUP DATABASE [BESMgmt] 
TO  DISK = N'C:\Backup\BESMgmt20101125.bak' 
WITH NOFORMAT, NOINIT,  
NAME = N'BESMgmt-Full Database Backup', 
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

La solución

La solución es simple e ingeniosa. Únicamente debemos “mentirle” para que crea que debe sobrescribir una base de datos existente utilizando WITH REPLACE. Aunque la base de datos no existe la ejecución es exitosa y resuelve el problema, permitiendo realizar el RESTORE.

Ejemplo

RESTORE DATABASE [BESMgmt] 
FROM  DISK = N'O:\MSSQL\Blackberry\BESMgmt20101125.bak' 
WITH REPLACE,  
MOVE N'BESMgmt_data' 
TO N'O:\MSSQL\Blackberry\BESMgmt.mdf',  
MOVE N'BESMgmt_log'      
TO N'O:\MSSQL\Blackberry\BESMgmt.ldf',  
NOUNLOAD,  STATS = 10
GO

Tags: , ,

Artículos

Truco para diseñar una dimensión tiempo de un Data Warehouse

por Jose Mariano Alvarez 18. noviembre 2010

CalendarioLa dimensión de tiempo existe habitualmente en cada data warehouse y la granularidad más usada es el día. Generalmente tiene muchos atributos pero solo algunos de estos atributos como por ejemplo el nombre del mes y el año pueden ser obtenidos fácilmente usando una expresión SQL aplicada a la fecha. Si la dimensión tiene atributos para dar soporte a múltiples lenguajes resulta a veces complicado construirla con el lenguaje SQL. Otros atributos no se pueden obtener mediante SQL ya que no hay mecanismos predecibles y dependen de decisiones humanas.

Otra característica de la dimensión tiempo es que suele tener muchos atributos como por ejemplo marcas de días feriados o no laborables, atributos de períodos fiscales o de temporadas, atributos relacionados a la fecha como el número de semana, la marca de último día del mes, y otros atributos muy útiles usados especialmente para la navegación y que deben estar integrados en la dimensión fecha mediante atributos dimensionales.

La gran ventaja de esta dimensión es que está completamente definida y especificada desde el inicio del proyecto del data warehouse. Pero la desventaja es que no tiene una fuente de datos convencional sino que se suele generar mediante algún mecanismo como una planilla o tabla cargada manualmente o mediante algún proceso.

La clave de la dimensión fecha

Todas las dimensiones fecha necesitan un atributo que representa a la fecha y un atributo para relacionar con la tabla de hechos. Debe haber al menos un registro que permita representar situaciones especiales como una fecha no aplicable o no informada o que no ha ocurrido aún y además es posible que desee distinguir varias de estas condiciones inusuales.

En estos casos en que se deben representar hechos relacionados a estas “fechas especiales”, las referencias foreign key en la tabla de hechos deben permitir referenciar a estos registros con “fechas inusuales” en la tabla de la dimensión fecha. Recordemos que el valor de estos atributos en los campos de la tabla de hechos no puede ser nulo, ya que debe estar relacionado con la tabla de la dimensión tiempo.

La clave principal de la dimensión fecha ideal debería ser una clave subrogada sin representación semántica, como por ejemplo un numero entero (que no representa una fecha), pero muchos diseñadores no pueden resistir la tentación de hacer que la clave sea legible como por ejemplo 20101116 significando el 16 de noviembre de 2010. Sin embargo, como con todas las claves inteligentes, los pocos registros especiales en la dimensión fecha harán que el diseñador utilice trucos para representarlas. Por ejemplo, la clave inteligente para una fecha “no aplicable” tendría que ser un valor sin sentido como por ejemplo 99999999, y esto trae aparejado que las aplicaciones que tratan de interpretar la fecha directamente para obtener información (como por ejemplo el mes) sin usar los atributos de la dimensión tengan inconvenientes porque no es una fecha válida.

Conclusión

En definitiva utilizar un tipo de dato fecha para el atributo clave de la dimensión fecha no es una buena elección y conviene que el valor este subrogado utilizando una clave entera que está oculto al usuario dentro de la meta data. El atributo representativo de la fecha debe ser un atributo que acepte representaciones especiales y no solamente representación de fechas válidas.

Referencia:

[PDF] Kimball Design Tip #51: Latest Thinking On Time Dimension Tables
http://www.rkimball.com/html/designtipsPDF/KimballDT51LatestThinking.pdf

Tags: ,

Ideas y nociones | Artículos

Como transferir los roles de servidor entre instancias de SQL Server 2005 o 2008

por Jose Mariano Alvarez 13. agosto 2010

Recientemente escribí un post que habla de cómo transferir los Logins entre instancias de SQL Server utilizando scripts documentados en la base de conocimiento de Microsoft.  Pueden encontrar este post en:

Cómo transferir los inicios de sesión y las contraseñas entre instancias de SQL Server

Además de transferir la contraseña, normalmente queremos que el nuevo Login tenga el mismo SID para evitar que los usuarios queden huérfanos dentro de las bases de datos migradas o transferidas. Esto lo realizan los script  documentados en la base de conocimiento que hago referencia en el post.

Sin embargo uno de los lectores me hizo notar que no había explicado que los scripts generados por estos documentos no generan los scripts correspondientes a los roles (funciones) de servidor que tenían en la instancia de origen.  Solo el método 2 del documento en inglés que transfiere los Logins desde el SQL Server 2000 al SQL Server 2005/2008 tiene la posibilidad de generar el script para transferir los roles de servidor entre las instancias. Las otras versiones del script no lo hacen.

Si ya hemos creado los Login con el script de estos documentos de la base de conocimiento y debemos  además, transferir los roles de servidor a esta nueva instancia, y nuestro origen es un SQL Server 2005 o un SQL Server 2008, podemos usar el siguiente script para generar el script de transferencia:

-- Genera el script con los Roles para los Logins
Select 
 'exec master.dbo.sp_addsrvrolemember @loginame=''' 
 + sp.name + ''', @rolename='''+sp2.name +''';' 
from 
master.sys.server_principals as sp 
join master.sys.server_role_members as srm 
on sp.principal_id = srm.member_principal_id 
join master.sys.server_principals as sp2 
on srm.role_principal_id=sp2.principal_id
where sp.type in ('S','U','G')


-- Genera el script con la base de datos por default (omision) para los Logins
Select 
 'ALTER LOGIN ['+ sp.name 
 +'] WITH DEFAULT_DATABASE = [' 
 + sp.default_database_name +'];'
from 
master.sys.server_principals as sp 
where sp.type in ('S','U','G')
and sp.default_database_name is not null

Tags: , ,

Artículos

Cifrado, Blackberry, Cloud Computing y Seguridad Nacional

por Jose Mariano Alvarez 3. agosto 2010

 

ClodComp Los algoritmos de cifrado y la seguridad nacional.

Hace unos años hubo una gran controversia acerca de la exportación de software y hardware que contenía algoritmos de cifrado “duros” debido a que los “enemigos” los podían usar para intercambiar información.

 

La controversia del AES y la seguridad nacional


Lo mismo ocurrió acerca de la selección del sucesor del DES como el algoritmo de cifrado, el cual iban a utilizar las agencias no militares y los contratistas del gobierno. La elección del AES como el algoritmo estándar de cifrado, una variación limitada en cuanto a sus prestaciones del algoritmo original Rijndael, fue anunciada por el Instituto Nacional de Estándares y Tecnología (NIST) como el estándar federal de procesamiento de la información. Esta controversia se basaba en el hecho de que se temía, de que los cambios introducidos al algoritmo ganador del concurso, permitían realizar un criptoanálisis a la información cifrada. Esto era algo que se sospechaba pero que oficialmente no se discutía, por temas de seguridad nacional.


Blackberry y la seguridad nacional


Recientemente dos países anunciaron restricciones a los servicios de e-mail y mensajería instantánea del Blackberry, utilizando como pretexto el que los servicios centralizan el manejo de los datos en servidores alojados en el extranjero. Esto puede ser verdad, pero sin embargo a veces puede haber sospechas de que en realidad son escusas que utilizan los gobiernos para prohibir la utilización de la tecnología por otros motivos, como por ejemplo los culturales, políticos o religiosos. Hay quienes dicen que la iniciativa más que buscar la protección de la seguridad nacional esconde un intento por controlar la información de la población.

Research In Motion (RIM), la creadora del Blackberry, hace que cierta información pase por sus servidores que están ubicados principalmente en Canadá. Si bien los datos viajan cifrados, el algoritmo usado no es conocido lo cual aumenta las sospechas.

Otro detalle no menor para los gobiernos es que puede alegarse que la información intercambiada constituye un peligro para la seguridad nacional, porque puede ser de terroristas y otros criminales y de esta forma puede ser intercambiada sin que puedan ser supervisadas por las autoridades.

Si bien las razones exactas del impedimento no están muy claras, el número de usuarios afectados podría ser mucho mayor si la represión se aplica también a extranjeros en viaje. Otro detalle no menor es que como la mayoría de los equipos pertenecen a empleados de áreas de las finanzas, y los bancos que los emplean dicen que están más preocupados por la seguridad de los datos frente a sus rivales que por la censura estatal.

El regulador de telecomunicaciones dice que el impedimento es el resultado del fracaso de que RIM se ajuste a las normas locales desde el año 2007. La prohibición se parece más un paso táctico para negociar con la empresa. En India pasó algo similar y alcanzaron un acuerdo.


Cloud Computing y seguridad nacional


La idea de Cloud Computing (informática en nube) ha ido ganando impulso en los últimos tiempos. La globalización ha llegado también a los servicios ofrecidos en internet. Sus promesas de reducción de costos y de mejora de la flexibilidad de TI han conseguido despertar el interés de las empresas. Pero el uso de modelos Cloud Computing también conlleva algunos riesgos relacionados con la conformidad, la disponibilidad y la integridad de los datos corporativos que deben superarse.

Debe tenerse en cuenta sobre todo que en última instancia, frente a las autoridades y clientes, el consumidor de los servicios es el responsable de mantener la confidencialidad, integridad y disponibilidad de los datos.

Esta nueva ola tecnológica trae también controversias de seguridad, que si bien son diferentes, en algunos aspectos pueden parecerse a lo que le está ocurriendo al Blackberry. El almacenamiento de la información fuera de las fronteras, o fuera del alcance de la justicia local, pero si al alcance de la justicia o medidas de los gobiernos extranjeros donde residen los Datacenters, pueden ser vistas como riesgos a la seguridad nacional.


Conclusión


Si no se elabora un acuerdo internacional en cuanto a la gestión global de la información, equivalente a lo que ocurre en el área de las transacciones comerciales con los acuerdos de la Organización Mundial de Comercio (OMC), esto puede retrasar el avance de la nube principalmente en países que no son económicamente “convenientes” para tener los Datacenters locales.

Tags: , ,

Artículos

Relación entre el log de transacciones (Transaction Log) y la captura de datos modificados (Change Data Capture)

por Jose Mariano Alvarez 25. julio 2010

Pequeño aumento de I/O en el Log de Transacciones.

En primer lugar, debemos tener en cuenta que, existe un pequeño aumento del I/O en los archivos del Log de Transacciones si la captura de datos modificados o Change Data Capture (CDC)  está habilitado en la base de datos. Esto ocurre debido a que se deben leer los datos de los cambios desde estos archivos del log de transacciones para poder identificar los cambios e incorporarlos en las tablas de captura. Además cuando corre el proceso o job de limpieza, se eliminan registros de las tablas de captura relacionadas y el log de transacciones también debe ser actualizado para respetar las reglas de las transacciones de las bases de datos.

Consecuencias de la captura de datos modificados o Change Data Capture en la reutilización de las entradas en el log de transacciones.

Cuando usamos una base de datos, una de las cosas que debiéramos tomar en cuenta es el tamaño que va a tener nuestro  registro o log de transacciones (Transaction Log). Para el correcto control del tamaño de los archivos que lo componen, si el modelo de recuperación es full, se realizan periódicamente tareas administrativas como el backup (o copia de seguridad) del log de transacciones. Esta tarea permite que en condiciones normales el mismo no crezca sin control ya que al completar la copia se pueden reutilizar las entradas y no hace falta que siga creciendo. Otra de las alternativas usadas es el modelo de recuperación simple que marca las transacciones completadas y grabadas en los archivos de datos como reutilizables lo que minimiza el uso del mismo a expensas de tener más posibilidades de recuperar datos en caso de una falla.

Es importante señalar que la captura de datos modificados o Change Data Capture (CDC) funciona correctamente en todos los modelos de recuperación. Cuando el CDC está habilitado en los modelos de recuperación simple o bulk-logged, los cambios realizados por las operaciones que normalmente se registran mínimamente, pasan a ser totalmente registrados en el log de transacciones para permitir la captura de todos los datos modificados. Además, cuando usamos la Captura de Datos Modificados o Change Data Capture se producen cambios en cómo se marcan las entradas que pueden reutilizarse en el log de transacciones. 

Si vemos con más detalle lo que ocurre, veremos que  los registros del log de transacciones permanecen activos hasta que el CDC los ha procesado. Esto significa, que en entornos en los que hay una gran tasa de cambios o la latencia de captura es grande, cuando el CDC no procesa frecuentemente las entradas de log de transacciones,  se acumulan entradas no reutilizables en el archivo del log de transacciones y por lo tanto este debe crecer porque el espacio no se puede reutilizar . Esto puede ocurrir tanto en el modelo de recuperación simple como después de un backuo o copia de seguridad de log de transacciones en el modelo de recuperación full (completa).

Consecuencias del log de transacciones lleno

Cuando un disco donde está el registro de transacciones se llena, no se puede reducir el tamaño del archivo del log de transacciones usando el comando shrink, hasta que la Captura de Datos Modificados o Change Data Capture (CDC) ha procesado todas las transacciones involucradas.  El problema es que el CDC no puede procesar las transacciones cuando los discos donde está el log de transacciones está lleno (o no puede crecer), porque el CDC inserta registros en las tablas de captura y estas operaciones también deben registrarse en el LOG de transacciones.

Si el problema es el espacio en el disco, la forma más fácil de recuperarse de esta situación es añadir otro archivo al log de transacciones,al menos de manera temporal, en un disco diferente donde haya espacio.

Tags: ,

Artículos

Migración a SQL Server 2008 cuando los nombres de los Data Source compartidos de Reporting Services contienen espacios

por Jose Mariano Alvarez 3. septiembre 2009

Si se realiza una migración o actualización de un reporte que hace referencia a un origen de datos compartido de Reporting Services 2005 a Reporting Services 2008, el informe dejará de funcionar después de la migración, ya que este proceso actualiza el nombre del data source compartido.

Quienes diseñaron reportes en el Business Intelligence Development Studio de SQL Server Reporting Services 2005 pueden utilizar nombres de data source compartidos con espacios en blanco. Sin embargo en la versión del 2008 ya no se pueden utilizar más. Por lo tanto no es posible crear nuevos data source con espacios en blanco.

En el IDE de Visual Studio 2005 si se puede utilizar fuentes de datos (data source) con espacios en blanco en el nombre.

Como puede verse en la siguiente imagen, en el IDE de Visual Studio 2008 no se puede usar fuentes de datos compartidas con nombres que contengan espacios en blanco en el nombre.

NombreDelDatasource

El problema es que si le cambiamos desde el sitio del Report Manager de Reporting Services el data source al que hace referencia el reporte que se encuentra en el servidor este cambio no tiene efecto a pesar que desde la interface el cambio queda impactado.

Existe una solución alternativa y consiste en editar el nombre del data source compartido del reporte para eliminar los espacios en blanco. Esto se realiza editando el contenido dentro del TAG <DataSourceReference> que se encuantra dentro del tag <DataSources>  en el archvo RDL del reporte como puede verse en la siguiente Imagen.

DatasourdeEnRDL

Tags: ,

Artículos

Powered by SQL Total Consulting


View Jose Mariano Alvarez's profile on LinkedIn

 Add to Technorati Favorites 

Calendar

<<  junio 2017  >>
lumamijuvido
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

View posts in large calendar

Locations of visitors to this page

Widget Twitter not found.

Root element is missing.X


Valid XHTML 1.0 Transitional

Valid CSS!