DBA Sql Forge Master

The SELECT permission was denied on the object 'sys...', database 'msdb', schema 'dbo'. When we try to access the SQL Server Agent related system tables , The following Error occurred Msg 229, Level 14, State 5, Line 1 The SELECT permission was denied on the object 'sys...', database 'msdb', schema 'dbo'. What are the Database role needed to access the following SQL Server Agent system tables ? USE MSDB Go The following system tables needed SQLAgentOperatorRole database role sysalerts, sysnotifications, sysoperators The following system table needed SQLAgentUserRole database role syscategories The following system tables needed TargetServersRole database role sysdownloadlist, sysjobs, sysjobservers, systargetservers, syssubsystems The following system tables needed db_Owner database role sysjobactivity, sysjobhistory, sysjobschedules, sysjobsteps, sysjobstepslogs, systargetservergroupmembers, syst

Muchos usuarios de SQL Server 2005 (desarrolladores y administradores) se quejan de lo mismo ¿Por qué tarda mucho tiempo en abrirse SQL Server Management Studio (SSMS)? Aún en caso de trabajar con grandes servidores y sin carga de trabajo, la primera vez que se abre SSMS tarda muchísimo tiempo (más de un minuto) y las sucesivas veces sigue tardando mucho (45 segundos). ¿Por qué tarda en arrancar SSMS? ¿Se puede corregir este comportamiento? ¿Qué sentido tiene? A todos nos ha incordiado este comportamiento típico de quizás nuestra herramienta preferida, SQL Server Management Studio, y sobre todo nos hemos hecho la misma pregunta ¿Por Qué? ¿Por qué tarda tanto tiempo en arrancar SSMS? ¿Por qué SSMS es tan lento en abrirse? Como todos sabemos, SQL Server Management Studio es una aplicación de código gestionado, es decir, que está desarrollada con .Net Framework, siendo esta la clave de este problema.  Parte del código de SSMS es código firmado digitalmente , lo cual implica, que al

Una limitación al utilizar OPENROWSET u OPENQUERY en SQL Server es que  no es posible utilizar variables para especificar los datos de conexión o la consulta (SQL o MDX) que se desea ejecutar . Entonces, al ejecutar consultas AdHoc con SQL Server (ya sea con OPENROWSET o con OPENQUERY) ¿Cómo especificar de forma variable o dinámica los datos de conexión? ¿Cómo especificar de forma variable o dinámica la consulta a ejecutar?. Esta funcionalidad que en ciertas ocasiones puede resultar muy-muy apetecible, es fácilmente remediable utilizando  SQL Dinámico  (ya sabemos, que el SQL Dinámico es una de esas funcionalidades tan queridas como odiadas entre los profesionales de SQL Server). Como ejemplo vamos a tomar el caso de OPENROWSET, aunque con OPENQUERY sería el mismo razonamiento. El escenario es el siguiente: ejecutar una consulta de SQL Dinámico, la cual utilice OPENROWSET u OPENQUERY, de tal modo que dicha consulta de SQL Dinámico será una simple variable de tipo VARCHAR o NVARCHA

Cada día que pasa, se utilizan más los Servidores Vinculados de SQL Server, para acceder a Orígenes de Datos OLEDB externos (consultar, importar datos, exportar datos, etc.). Este capítulo pretende responder a las principales dudas y preguntas sobre Servidores Vinculados en SQL Server (es casi un pequeño manual sobre Servidores Vinculados ;-) ¿Qué es un Servidor Vinculado? ¿Para qué sirve un Servidor Vinculado? ¿Cómo crear un Servidor Vinculado? ¿Cómo configurar un Servidor Vinculado? ¿Cómo y qué configurar de un Proveedor OLEDB para utilizar con un Servidor Vinculado? ¿Cómo acceder y consultar tablas y vistas de un Servidor Vinculado? ¿Cómo ejecutar un procedimiento almacenado remoto a través de un Servidor Vinculado? ¿OPENQUERY o Notación de 4 Partes? Un Servidor Vinculado es una definición de una Cadena de Conexión OLEDB y un Proveedor OLEDB que asociamos a un  nombre lógico , es decir, nos permite definir un nombre para el servidor vinculado, y a dicho nombre especificarle qué

Una buena práctica inmediatamente después de instalar SQL Server 2005 es cambiar el Puerto TCP de escucha, por múltiples motivos: Seguridad, Configuración de reglas de acceso de Firewall, Aplicaciones cliente que requieren un puerto TCP estático para SQL Server, etc. En este Artículo se explica cómo averiguar en qué puerto TCP escucha SQL Server 2005, cómo cambiar el puerto TCP de escucha de SQL Server 2005, etc. Resulta de gran interés ser capaz de responder a la pregunta  ¿En qué puerto TCP escucha SQL Server?  Por defecto, una  Instancia por Defecto de SQL Server 2005  queda configurada durante la instalación para escuchar en el  puerto TCP-1433 , sin embargo,  las Instancias con Nombre  quedan configuradas durante el proceso de instalación para escuchar en  puertos TCP dinámicos , por lo tanto, cada vez que se inicie la Instancia puede que escuche en un puerto diferente. Esta situación puede resultar problemática, por un lado desde el punto de vista de la seguridad (el hecho d

Este capítulo explica cómo poder modificar los datos de las tablas del sistema de SQL Server 2005 y cómo modificar por procedimientos almacenados del sistema en SQL Server 2005 (ojo: estas configuraciones no están soportadas ni son prácticas recomendables). Se habla del procedimiento almacenado de sistema sp_MS_marksystemobject, de la opción de configuración allow updates, de la base de datos MSSQLSystemResource, en que modo (trace flag) arrancar la instancia de SQL Servere 2005 para conseguir realizar los cambios del sistema deseados, etc. En ocasiones resulta necesario modificar directamente los objetos del sistema de SQL Server, existiendo principalmente dos casuísticas:  modificar las tablas del sistema  para reflejar manualmente cierta configuración, y  modificar los procedimientos almacenados del sistema para mejorar su rendimiento. En  SQL Server 2000  es posible utilizar el procedimiento almacenado del sistema  sp_configure para activar la opción  allow updates . De este

Este capítulo explica los operadores WITH CUBE y WITH ROLLUP, que junto a la función GROUPING resulta de gran utilidad en muchos casos. Resultan una alternativa muy interesante a la utilización de la cláusula COMPUTE BY, y además, están disponible desde SQL Server 2000. Se explica el tratamiento de los nulos (NULL) en las consultas WITH CUBE y WITH ROLLUP, y se incluyen varios ejemplos de WITH CUBE y WITH ROLLUP, para facilitar su uso. En la realización de consultas de grupo (es decir, utilizando la cláusula GROUP BY), habitualmente resulta necesario obtener valores totales o subtotales adicionales a los que se pueden obtener sólo con la cláusula GROUP BY. Ante esta situación, es posible utilizar la cláusula  COMPUTE BY , sin embargo, COMPUTE BY ofrece múltiples conjuntos de resultados que hace difícil su procesamiento. Por suerte, disponemos también de los operadores  WITH CUBE  y  WITH ROLLUP , que junto con la función  GROUPING  nos permite obtener el resultado deseado utilizan

Este capítulo explica los comportamiento de transacciones explícitas (explicit transactions ó autocommit) y transacciones implícitas (implicit transactions), ambos disponibles en SQL Server (por defecto se utilizan transacciones explícitas). Se explica la relacción de estos comportamientos con la sentencia BEGIN TRAN y con los modos de aislamiento, así como con las transacciones anidadas (nested transactions). Se explica también como establecer el modo de transacciones explícitas o implícitas (sentencia SET IMPLICIT_TRANSACTIONS), etc. SQL Server utiliza por defecto el modo de transacciones explícitas  (el conocido  auto commit ), lo cual implica que , que la ejecución de una sentencia DML (ej: UPDATE) se confirma automáticamente. Por ello, si deseamos ejecutar varias sentencias DML (ej: varios UPDATE), será necesario de forma explícita iniciar una transacción (BEGIN TRAN), ejecutar las sentencias DML deseadas, y finalmente confirmar o deshacer la transacción (COMMIT ó ROLLBACK).

Esta capítulo explica qué es el nivel de aislamiento (isolation level) de una transacción, el comportamiento de SQL Server en operaciones de lectura o de escritura, se detallan los diferentes niveles de aislamiento basados en bloqueos (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) y los niveles de aislamiento basados en versionado de filas (READ COMMITTED SNAPSHOT, SNAPSHOT), se explican los males de la concurrencia (lecturas sucias, lecturas no repetibles, lecturas fantasma, y conflictos de actualización), como establecer el nivel de aislamiento deseado (SET TRANSACTION ISOLATION LEVEL y las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION), cómo conecer el tiempo máximo de bloqueo (@@LOCK_TIMEOUT) y como establecer el tiempo máximo de bloqueo (SET LOCK_TIMEOUT), etc. El nivel de aislamiento de una transacción (transaction isolation level)  define el grado en que se aísla una transacción de las modificaciones de recursos o datos rea

Este breve capítulo se limita a presentar los operadoes UNION, UNION ALL, INTERSECT, y EXCEPT. El motivo por el cual he decidido escribir este capítulo es debido, a que igual que mucha gente conoce los operadores UNION y UNION ALL, pocos conocen EXCEPT e INTERSECT. Más aún, aquellos que vienen de ORACLE, en ocasiones sienten nostalgia de su MINUS... bien, pues EXCEPT es equivalente al MINUS de ORACLE, e INTERSECT existe en ambos motores (SQL Server y ORACLE), al igual que UNION y UNION ALL. En ocasiones puede resultar de utilidad el uso de este tipo de operadores, de tal modo, que se pueda obtener la unión, la intersección o la diferencia de dos (o más) conjuntos de resultados. Los operadores UNION y UNION ALL ya llevan tiempo en SQL Server. Por el contrario, los operadores  EXCEPT e INTERSECT están disponibles desde SQL Server 2005 . De este modo, se obtiene una alternativa a los operadores UNION/UNION ALL/MINUS/INTERSECT que ofrece ORACLE, sin tener que elaborar consultas alter

Este capítulo explica el concepto de Intercalación (Collation) de las bases de datos SQL Server. Se explica las consideraciones de configuración de Intercalación (Collation) a nivel de instancia de SQL Server (es decir, de las bases de datos del sistema), peculiaridades de la configuración de Instancia a nivel de de base de datos (distintas bases de datos pueden utilizar una Intercalación diferente), etc. También se explica cómo cambiar la intercalación de una columna (ALTER TABLE ALTER COLUMN COLLATE), cómo cambiar la intercalación de una base de datos, la utilización de la función fn_helpcollations, la utilización de la palabra clave COLLATE en la cláusula WHERE, etc. El concepto de  Intercalación (Collation)  hace referencia al patrón de bits utilizado para representar/almacenar cada carácter, y en consecuencia también se refiere a las reglas utilizadas para ordenar y comparar caracteres. Evidentemente, se trata de un concepto que  afecta sólo a los campos de texto . En la ins

Durante el diagnóstico de problemas con SQL Server, habitualmente es suficiente con la ejecución de trazas de SQL Profiler (y su posterior análisis) y la captura de determinados contadores de rendimiento (y su análisis posterior) con un monitor (ej: MOM2005, SCOM, Patrol, etc.). Sin embargo, en alguna ocasión surge la duda de averiguar qué ha ocurrido en una base de datos SQL Server explorando el LOG. Este capítulo explica las utilidades disponibles con el producto (fn_dblog y DBCC LOG), se incluyen consultas de ejemplo, y se incluye referencias a herramientas de terceros (Apex SQL Log, Log Explorer, SQL Log Rescue, ApexSQL Audit, Lumigent Audit DB, Omni Audit, SQLLog, Upscene SQL Log Manager). El contenido del LOG de SQL Server utiliza un formato propietario, bajo el cual, almacena la información de las modificaciones realizadas en la base de datos. En teoría no se ofrece ningún mecanismo para ver el contenido del LOG de una base de datos SQL Server. Sin embargo, existen dos méto