Este Artículo, pretende servir como un Manual de SQL Server, en el cual poder aprender pequeños detalles de SQL Server a través de Preguntas y Respuestas. La selección de dichas Preguntas, la he realizado tomando como fuente algunas de las Preguntas más habituales en los Grupos de Noticias de Microsoft (Newsgroups), aunque también he tomado como fuente, las Preguntas más habituales que me han realizado mis Compañeros, mis Clientes y mis Alumnos, a lo largo del tiempo.

Después de recopilar las Preguntas de SQL Server que aquí he incluido, he elaborado sus respuestas, intentando utilizar un lenguaje cordial, y sobre todo, intentando explicarlo a mi modo, a lo Guille ;-) Este no es un Tutorial de SQL Server formal, y su contenido NO se puede obtener de ningún libro. Intento elaborar mis propias respuestas, redactadas a mi manera, en muchos casos después de realizar muchas pruebas, investiguar en Internet y en la propia documentación de SQL Server, y siempre que puedo en base a experiencia real en entornos SQL Server de Producción en los que he trabajado.

• ¿Qué arquitectura de procesador (CPU) elegir para SQL Server? ¿32-bit o 64-bit? ¿x86, x64 ó IA64 Intel Itanium?
  ¿Qué arquitectura de procesador (CPU) elegir para SQL Server? ¿32-bit o 64-bit? ¿x86, x64 ó IA64 Intel Itanium? SQL Server está disponible en distintas arquitecturas de procesador (CPU). Sin embargo, la elección de una arquitectura de procesador para SQL Server implica también su elección para el hardware y para el sistema operativo, con el correpondienten impacto en costes. Además, la elección de una arquitectura de procesador, puede implicar ciertas limitaciones de utilización del producto (direccionamiento de memoria, disponibilidad de drivers de Sistema Operativo, Conectividades - ODBC, OLEDB, .Net Providers, etc. -, disponibilidad de iFilters, disponibilidad de software, etc.). Entonces ¿Qué arquitectura de procesador me interesa para mi SQL Server?
  
  
• ¿Qué diferencia hay entre Instancia y Base de Datos?
  ¿Qué diferencia hay entre Instancia y Base de Datos? Esta es una pregunta muy habitual, sobre todo, para aquellos que vienen de trabajar con otros motores de base de datos (ej: ORACLE) y también para aquellos que empiezan a trabajar con SQL Server (sin experienza). ¿Cuántas instancias de SQL Server me interesa mantener? ¿Cómo puedo organizarlas? ¿Qué motivos pueden implicar la utilización de una instancia dedicada? ¿utilizar múltiples instancias o múltiples bases de datos, cuando sólo disponemos de un único servidor?
  
  
• Base de Datos Sospechosa (Suspect), recuperación con sp_resetstatus y DBCC DBRECOVER, y el Modo de Emergencia
  Un problema típico en Administración de Bases de Datos SQL Server, es encontrar una Base de Datos Sospechosa (Suspect). Una base de datos está en estado Sospechosa (Suspect) cuando SQL Server no es capaz de garantizar la integridad de sus datos, siendo este un error habitualmente relacionado con problemas de acceso a disco, y con caídas no ordenadas de SQL Server (ej: pérdida del suministro eléctrico que pueda provocar corrupción o pérdida de información de los discos). Cuando una base de datos está en estado Sospechoso (Suspect), no es posible acceder a la misma ¿Cómo reparar una Base de Datos Sospechosa (Suspect)? ¿Qué hace sp_resetstatus? ¿Cómo ejecutar sp_resetstatus y DBCC DBRECOVER? ¿Es necesario reiniciar la instancia? ¿Cómo establecer el Modo de Emergencia para extraer datos?
  
  
• ¿Qué diferencia hay entre Inicio de Sesión y Usuario?
  En este capítulo se explica la diferencia entre Inicio de Sesión y Usuario de Base de Datos. Al contrario que en otros motores de base de datos, SQL Server tiene dos niveles de profundidad en la definición de sus Usuarios. Por un lado está el Inicio de Sesión (el usuario con el que nos conectamos, el de la password) y por otro lado está el Usuario de Base de Datos (se le asigna al Inicio de Sesión) que es sobre el que se asignan los permisos de acceso a los objetos de base de datos. Esta es una duda típica en quienes empiezan con SQL Server. También se explicá el SID y el UID, que son los usuarios huérfanos (orphaned users) y como repararlos (sp_change_users_login ), syslogins, sysusers, CREATE LOGIN, CREATE USER, sp_addlogin, sp_grantlogin, sp_adduser, sp_addsrvrolemember, sp_addrolemember, etc.
  
  
• ¿Qué diferencia hay entre Propietario (object owner) y Esquema (schema)?
  Este capítulo explica los conceptos de Propietario y Esquema en SQL Server, así como la resolución de nombres de objetos en SQL Server. El concepto de Esquema, es un cambio importante frente a versiones anteriores de SQL Server, explicándose el cambio producido con los conceptos de Propietario y Esquema entre SQL Server 2000 y SQL Server 2005. Se explica el concepto de esquema por defecto, la utilización de GRANT - DENY - REVOKE con la cláusula ON SCHEMA, cómo cambiar el propietario de un objeto en SQL Server (sp_changeobjectowner), cómo cambiar el propietario de un esquema (ALTER AUTHORIZATION SCHEMA), ventajas de los esquemas al eliminar usuarios cambiando el esquema bajo es que están sus objetos (ALTER SCHEMA TRANSFER), etc.
  
  
• ¿Qué función tiene cada una de las bases de datos del sistema?
  MASTER, MSDB, MODEL, TEMPDB, DISTRIBUTION y MSSQLSYSTEMRESOURCE. ¿Qué función tiene cada una de las bases de datos del sistema? ¿Para qué sirve MASTER? ¿Para qué sirve TEMPDB? ¿Para qué sirve MODEL? ¿Para qué sirve MSSQLSYSTEMRESOURCE? Este capítulo explica cuál es la función de cada una de las base de datos del sistema, algo de vital importancia para conocer SQL Server, su funcionamiento, consideraciones cara al diseño de planes de contingencia (backup y restores) y optimización de rendimiento (tunning) de base de datos, etc.
  
  
• ¿Cómo mover las bases de datos del sistema? ¿Cómo mover MASTER, MODEL, MSDB ó TEMPDB?
  Una buena práctica después de instalar SQL Server es cambiar la ubicación de las bases de datos del sistema a los discos y directorios que deseemos. Especialmente interesante es el hecho de cambiar la ubicación de TEMPDB, y también al instalar un Cluster de SQL Server, ya que hasta que no finalice el proceso de Instalación de SQL Server no podremos añadir discos adicionales Esta capítulo explica como mover las bases de datos del sistema (MASTER, MSSQLSYSTEMRESOURCE, MODEL, MSDB ó TEMPDB) en SQL Server 2005.
  
  
• Tamaño inicial de TEMPDB ¿Cómo aumentar TEMPDB? ¿Cómo reducir TEMPDB?
  Una buena práctica después de instalar SQL Server (y que interesa revisar periódicamente) es tener bien dimensionada la base de datos TEMPDB, es decir que el tamaño inicial de TEMPDB sea suficiente, y en consecuencia no sea necesario que TEMPDB crezca ni tampoco reducir TEMPDB (SHRINK). Esta artículo explica brevemente para qué sirve TEMPDB, explica camo cambiar el tamaño inicial de TEMPDB (aumentar o reducir), cómo reducir TEMPDB, cuántos ficheros son recomendables para TEMPDB, etc.
  
  
• ¿Por qué crece tanto mi base de datos?
  ¿Por qué crece tanto mi base de datos? Un problema muy habitual (bueno, realmente no es un problema, como ahora veremos) al trabajar con SQL Server, es que una base de datos crezca y crezca hasta incluso agotar todo el espacio de disco disponible. En muchos casos, esto es debido al modo de registro completo (Recovery Full) y a la configuración de Copias de Seguridad del LOG. En este capítulo se explica este problema, así como soluciones y alternativas.
  
  
• ¿Cómo se puede reducir una base de datos?
  Una práctica habitual en la administración de SQL Server, es tener que reducir una base de datos, ya sea por problemas de configuración del modo de registro y copias de seguridad de LOG (ej: Modo de Registro Completo, sin hacer Backup LOG), por haber eliminado información de la base de datos, etc. En este capítulo se explica cómo reducir una base de datos en SQL Server y qué problemas se pueden producir al intentar reducir una base de datos. Se explican los comandos DBCC SHRINKDATABASE y DBCC SHRINKFILE, los ficheros de log virtuales y el comando DBCC LOGINFO(), cómo ver el espacio usado del LOG con DBCC SQLPERF(LOGSPACE), cómo truncar el LOG de una base de datos con la sentencia BACKUP LOG WITH TRUNCATE_ONLY, etc.
  
  
• ¿Qué es el Modo de Recuperación o Modo de Registro? Modos de Recuperación Simple, de Registro Masivo (BulkLogged), y Completo (Full). Operaciones de Registro Mínimo.
  El Modo de Recuperación, también conocido como Modelo de Recuperación ó Modo de Registro, es una opción de configuración de base de datos que indica cómo se gestiona el uso del LOG de Transacciones de SQL Server para dicha base de datos (esta opción se configura para cada base de datos de forma independiente). En función de la configuración del Modo de Recuperación debemos elegir la estrategia de Backup y Restauración de SQL Server (o viceversa), y podremos mejorar el rendimiento de ciertas operaciones denominadas Operaciones de Registro Mínimo, minimizando las escrituras en el LOG de SQL Server (y en consecuencia, minimizando el tamaño del LOG de SQL Server).
  
  
• ¿Por qué aumenta tanto la memoria RAM consumida por SQL Server?
  SQL Server presenta un comportamiento, para muchos algo peculiar, del consumo de memoria (es decir, como va tomando la memoria del Sistema Operativo, y como la va liberando). Este comportamiento, es una de las principales dudas existenciales de SQL Server para quienes empiezan. En este capítulo, explicamos cómo SQL Server toma y libera memoria, las opciones de configuración para limitar el consumo de memoria de SQL Server (min server memory y max server memory), la utilización de sp_configure y RECONFIGURE para comprobar o cambiar la configuración de limitación de memoria de SQL Server, consideraciones de la memoria al utilizar múltiples instancias de SQL Server, etc.
  
  
• ¿Cómo trabajar con Fechas en SQL Server?
  Este capítulo explica las dudas frecuentes al trabajar con fechas en SQL Server: tipos de datos de fecha en SQL Server y sus rangos de valores, realización de consultas sobre fechas y utilización de funciones de fecha habituales (utilizar BETWEEN, DATEPART, DATEDIFF, etc), realización de castings (cambiar datos de un tipo a otro, ej: VARCHAR a DATETIME) con CAST y CONVERT, cómo obtener la fecha actual en SQL Server (GETDATE y GETUTCDATE), utilización de la opción de configuración SET LANGUAGE, cómo obtener la fecha sin la hora, ¿Calendario Juliano o Calendario Gregoriano?, etc.
  
  
• ¿Cómo organizar los Ficheros y Grupos de Ficheros en SQL Server?
  Este capítulo explica las diferencias existentes en SQL Server entre ficheros de datos, ficheros de LOG y grupos de ficheros. Se explica los conceptos de grupo de ficheros por defecto, algunas recomendaciones sobre el número de ficheros y de grupos de ficheros a utilizar (ej: en función del número de CPUs - afinidad de CPU), recomendaciones sobre los niveles RAID a utilizar (¿RAID1 ó RAID5?), etc
  
  
• ¿Es necesario Reindexar o Defragmentar nuestros datos en SQL Server? ¿Qué diferencia existe en Reindexar y Defragmentar?
  Este capítulo explica el problema de la Fragmentación de SQL Server (tanto en el sistema de ficheros como en base de datos, esto es, en los índices). Se explica cómo defragmentar un disco o volumen y cómo manterner defragmentado un disco o volumen. Se explican las consideraciones de las tablas SIN índices (Heap) y de las tablas con índices agrupados (clustered index), cómo comprobar la fragmentación en SQL Server con DBCC SHOWCONTIG y sys.dm_db_index_physical_stats, etc. Por último se explica las alternativas existentes para corregir la fragmentación: Eliminar y volver a crear el índices (DROP INDEX y CREATE INDEX), Recontruir el índice (DBCC DBREINDEX, CREATE INDEX WITH DROP_EXISTING o ALTER INDEX REBUILD) y Defragmentar el índice (DBCC INDEXDEFRAG o ALTER INDEX REORGANIZE).
  
  
• ¿Es posible leer el LOG de SQL Server? ¿Puede utilizarse fn_dblog y DBCC LOG?
  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).
  
  
• ¿Qué es la Intercalación (Collation) en SQL Server? ¿Es posible cambiar la Intercalación de una base de datos?
  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.
  
  
• ¿Qué operadores para combinar resultados de consultas existen en SQL Server? UNION/UNION ALL/EXCEPT/INTERSECT
  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.
  
  
• ¿Qué es el nivel de aislamiento (Isolation Level) de una Transacción? ¿Qué niveles de aislamiento ofrece SQL Server?
  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.
  
  
• ¿Es posible cambiar el modo de transacciones explícitas (auto commit) de SQL Server? ¿IMPLICIT_TRANSACTIONS ON or OFF?
  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.
  
  
• Agrupando datos con WITH CUBE, WITH ROLLUP y GROUPING
  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.
  
  
• ¿Es posible modificar los objetos del sistema en SQL Server 2000? ¿Es posible modificar los objetos del sistema en SQL Server 2005?
  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 qué puerto TCP escucha SQL Server 2005? ¿Cómo cambiar o configurar el puerto TCP de escucha de una Instancia de SQL Server 2005?
  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.
  
  
• ¿Qué es un Servidor Vinculado? ¿Para qué sirve un Servidor Vinculado? ¿Cómo crear un Servidor Vinculado? ¿Cómo configurar un Servidor Vinculado?
  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?
  
  
• ¿Cómo ejecutar consultas dinámicas sobre OPENROWSET o sobre Servidores Vinculados (OPENQUERY)?
  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).
  
  
• ¿Por qué tarda mucho tiempo SQL Server Management Studio (SSMS) en abrirse?
  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?