Deja un comentario

Missing an Index? Check for it ..


ownerdba:

good

Originalmente publicado en DBA and SysAdmin World:

SqlServer2005
Behind the scene
There was a story when I created this script. There was an issue on our production server. After investigated, there was no index on one table but the table has an index on testing environment. Looks like when published the table, the DBA missed publish the index. After this issue, my supervisor asked me to create a script for listing all tables that do not have an index. Every table should be have an index obviously. Below script could not run on SQL Server 2000 and previous version.

Script
Below the script for list index availability of the tables.

Result of the script

Column Name Description
TableName Name of the table
SchemaName Name of the schema
HasIndex Yes if the table has an index vice versa
IndexName Name of the index
IndexKeys Keys of the index
IsPrimaryKey Is this index a primary key?
IndexType Type of the…

Ver original 455 palabras más

Deja un comentario

Buenas practicas para respaldar y restaurar bases de datos en SQL Server


Una de las responsabilidades dentro de las tantas asignadas a un DBA, es definir una estrategia de respaldos y procurar la recuperación de los datos cuando se requiera,  en otras palabras realizar los respaldos y las restauraciones de los datos.

¿Que es un backup?

¿ Cuantos tipos de respaldos existen ?

¿Como optimizar mi estrategia de respaldos?

Son algunas de las respuestas que se responderan con el siguiente articulo.

 

Una aplicación SQL Server en funcionamiento en realidad es una colección de bases de datos. Además de los datos en sí, incluye bases de datos del sistema y el registro de transacciones. Para poder restaurar la aplicación sin tropiezos, todo esto tiene que estar protegido. A continuación encontrará algunos consejos y buenas prácticas de Restauración y backup con SQL Server.

A diferencia de muchos programas, SQL Server permite la realización de backups mientras los usuarios están activos y se están procesando transacciones. Esto significa que se puede  hacer backup mientras se está utilizando el sistema. Pero como el backup de SQL Server ocupa recursos, en especial E/S, es mejor realizar backups completos en momentos en los que el sistema soporta poca carga.

Acorte la duración del backup de datos

Si el rendimiento global se está resintiendo debido a la duración de los backups, se pueden hacer varios backups cortos para abreviar la duración total del tiempo dedicado al backup. Una manera de acortar los backups consiste en utilizar la compresión de datos de backup. Otra forma de abreviar la duración del backup consiste en hacer la copia de seguridad de la base de datos en un disco. Ahora bien, si se hace backup en un disco, no hay que hacerlo en el mismo disco utilizado para guardar la base de datos o el registro de transacciones. De lo contrario, no sólo se merma el rendimiento, sino que también puede afectar a la posibilidad de recuperación de la información en caso de fallo del disco.

Métodos de backup combinados

SQL Server ofrece tres métodos de backup básicos: completo, diferencial y de transacciones. Son opciones de backup incorporadas en el propio SQL Server, por lo que no es necesaria una aplicación de backup independiente. Un backup completo realiza una copia de seguridad de todo. Es el más largo, el que más tarda y el que más recursos utiliza. Un backup diferencial sólo copia lo que ha cambiado desde el último backup completo. Esto hace que los backups sean más rápidos, pero las restauraciones son más lentas, puesto que es necesario reconstruir la base de datos. Un backup del registro de transacciones sólo copia el registro de transacciones desde el backup anterior del mismo. Es muy rápido, pero la reconstrucción de una base de datos a partir de una cadena de backups de registros de transacciones es el más lento de los métodos de restauración.

Además de estos tres métodos de backup de toda la base de datos; SQL Server también permite backup individualmente archivos o grupos de archivos, lo cual puede resultar útil para proteger archivos importantes o para hacer backups de  bases de datos muy grandes.

La selección del método de backup más adecuado para cada organización depende de la índole de la base de datos que se desea proteger, y concretamente de la frecuencia con la que cambia, de su tamaño, y de su importancia para la entidad. Algunas bases de datos no son muy grandes y cambian con relativamente poca frecuencia. Se pueden proteger mediante backups completos realizados diariamente o a intervalos semanales. Otras, en especial las bases de datos de transacciones críticas, son objeto de backup completo con la mayor frecuencia viable.

Hacer backup con frecuencia del registro de transacciones

Aparte de la propia base de datos, el registro de transacciones contiene los datos más críticos de una base de datos SQL Server. El registro de transacciones recoge toda la actividad y se puede utilizar para realizar restauraciones hasta un momento determinado (point-in-time, PIT). La ventaja del registro de transacciones es que se puede hacer backup con frecuencia, manteniéndolo muy actualizado. También dispone de backups PIT o casi PIT, entre otras más convencionales. Hay que señalar que un backup de transacciones sólo copia hasta el anterior backup de transacciones. Eso significa que para conseguir una restauración completa, hay que restaurar una secuencia de backups de transacciones. La fuerza del backup de un registro de transacciones reside en su capacidad de restaurar hasta el minuto anterior, o casi.

El registro de transacciones se debería hacer backup varias veces al día. Muchas organizaciones que utilizan una base de datos activa, como una base de datos de transacciones, le hacen backup  cada 10 minutos más o menos.

Hacer backup de bases de datos del sistema SQL Server

El otro componente vital de una aplicación SQL son las bases de datos del sistema, entre ellas msdb y master. Contienen información vital, como la configuración del sistema, y son necesarias en caso de restauración completa. Cambian con menor frecuencia y se deberían de hacer backup  al menos una vez por semana, o a diario si se trata de un entorno activo (donde las transacciones de datos son frecuentes): En el caso de las bases de datos master, hay que realizar backups al menos cada vez que se produce un cambio en los ajustes a nivel de configuración del servidor o de la base de datos, o si se introduce cualquier cambio en los detalles de las cuentas de inicio. Se puede copiar las bases de datos del sistema mientras se está ejecutando la aplicación.

Hacer backup de  la partición del sistema al menos cada vez que se modifique la configuración

Técnicamente, la partición del sistema no forma parte de SQL Server, pero una partición del sistema sin hacer backup puede dificultar la recuperación de la base de datos. Es importante mantener un backup  actualizado de la partición del sistema, lo cual significa que hay que hacer backup al menos cada vez que se introduzca un cambio en la configuración del sistema; los backup periódicos son aún mejores.

Garantice la seguridad de la base de datos

Cerciórese de que su base de datos está bien protegida. Por ejemplo, cuando utilice el sistema de archivos para realizar backups, sólo debe permitir que accedan las carpetas y archivos la cuenta de servicio de SQL y el administrador de la base de datos.

En la orden de backup no utilice la opción de contraseña para proteger con ella el backup. Ha sido objeto de críticas y está previsto que desaparezca en las versiones futuras de SQL Server.

Cuando realice backups, utilice la opción de suma de comprobación de la orden de backup y compruebe periódicamente sus backups mediante la orden Comprobar solamente la restauración.

Por último, cerciórese de que sus parches de seguridad estén actualizados y correctamente instalados – no sólo en el servidor SQL, sino también en el hardware y el sistema operativo que lo sustentan.

Información sobre el autor: Rick Cook está especializado en temas relacionados con el almacenamiento y la administración del almacenamiento.

 

fuente:  http://www.searchstorage.es/respaldo-de-datos/buenas-practicas-de-backup-y-recuperacion-de-datos-en-sql-server/

 

 

Espero les sirva,  Saludos

 

Deja un comentario

SQL Server Solución “servidor frontend – servidor backend”


Frontend backend sql server?

como funciona arquitectura frontend backend?

servidor fronted – servidor backend?

Arquitectura de alta disponibilidad para bases de datos

En el ambito de TI seguramente habras escuchado alguna vez la terminologia back end front end, bueno aqui le straigo un post muy simple, concreto y explicativo acerca de la solución que representa esta arquitectura de servidores.

Solución normalmente indicada para aquellos proyectos de tamaño medio que suelen ofrecer un sitio web con contenido dinámico que requiere de un uso considerable de una base de datos.

Habitualmente el servidor de frontend albergará las aplicaciones “públicas” como web, servidor de correo, etc., mientras que en el servidor de backend se almacenará la información de la base de datos. Por el distinto uso al que son sometidos es recomendable que los equipos de backend tengan una configuración diferente a los de frontend, con una capacidad de almacenamiento superior y una mayor velocidad de acceso a disco. En esta arquitectura es recomendable que ambos servidores posean una mayor tolerancia a fallos, por lo que se aconseja contar con equipos con controladora de discos RAID y doble fuente de alimentación.

Solución con múltiples servidores

Esta es la solución ideal para  proyectos grandes que han de prestar múltiples servicios (web, correo, acceso a bases de datos, streaming, comercio electrónico, dns etc), con la garantía de un mayor rendimiento, ya que cada servicio es asignado a un servidor determinado que tendrá una configuración hardware adaptada al servicio. Esto permite además que cada uno de los servidores pueda utilizar la plataforma que más convenga (Windows Server, Debian Linux u otro), dependiendo de la utilización que se le vaya a dar al mismo.

En el ejemplo que ilustramos se requiere de varios servidores de frontend con diferentes Sistemas Operativos debido a que cada uno de ellos está especializado en ofrecer aplicaciones concretas y, por otro lado, cuenta con 2 servidores backend en clúster para albergar la Base de Datos. Del mismo modo que en la solución anterior, es recomendable que cada servidor posea una mayor tolerancia a fallos: controladora RAID y fuente de alimentación redundante.

 

Espero les sirva para clarificar los conceptos,

Saludos

Fuente:  http://www.acens.com/hosting-gestionado/soluciones-avanzadas/frontend-backend.html/

1 comentario

Compresión o Reducción de la Tempdb (shrink tempdb)


Este artículo discutirá sobre tres métodos que puedes usar para reducir el tamaño de la base de datos tempdb, el primer método te da un completo control del tamaño de los archivos de la
tempdb pero requiere que se reinicie el servicio de SQL Server.

El segundo método minimiza la tempdb completa, con algunas limitaciones dentro de ellas reiniciar el servicio. El tercer método
permite minimizar el tamaño de archivos individuales. Los últimos dos métodos requieren que no exista actividad alguna en la base de datos tempdb durante el proceso de shrink.

Información de la tempdb

La tempdb es un espacio de trabajo temporal, estas son algunas de las funciones:

  1. ·        
    Almacenamiento de las tablas temporales creadas explícitamente.
  2. ·        
    Tablas de trabajo que contienen resultados intermedios creados durante el procesamiento de consultas y la clasificación.
  3. ·        
    Se encarga de materializar los cursoresestáticos.

SQL Server registra sólo la información necesaria en el
registro de transacciones de tempdb para deshacer una transacción, pero no para
rehacer las transacciones de base de datos durante la recuperación. Esta
función aumenta el rendimiento de las instrucciones INSERT en tempdb. Además,
no hay necesidad de registrar información para rehacer transacciones porque
tempdb se vuelve a crear cada vez que se reinicie SQL Server, por lo que no
tiene ningún transacciones para rehacer o deshacer. Cuando se inicia SQL
Server, tempdb se vuelve a crear mediante el uso de una copia de la base de
datos model y se restablece a su último tamaño configurado

 

 

Método 1 para comprimir Tempdb
Este método requiere que se reinicie SQL Server.

 1.      Parar SQL Server. Abrir el command prompt,y entonces iniciar SQL Server con el siguiente comando:

sqlservr -c –f

 

Los parámetros –c y –f le dicen que s SQL que inicie con el modo de configuración mínimo para la tempdb con un tamaño de 1 MB para archivos de dato y 0.5 MB para el log.

 

NOTA: Si utiliza una
instancia nombrada de SQL Server, debe cambiar a la carpeta correspondiente
(Archivos de programa \ Microsoft SQL Server \ MSSQL $ nombre de instancia \ Binn) y utilice la opción-s (-s%% instance_name).

 2.      Conecte a SQL Server con el Analizador de consultas y ejecute los siguientes comandos Transact-SQL:

 ALTER DATABASE tempdb MODIFY FILE

(NAME = ‘tempdev’, SIZE = target_size_in_MB)

–Desired target size for the data file

 

ALTER DATABASE tempdb MODIFY
FILE

(NAME = ‘templog’, SIZE =
target_size_in_MB)


–Desired
target size for the log file

 

3.      
Stop SQL Server pulsando Ctrl + C en la ventana de símbolo del sistema, reinicie SQL Server como un servicio,
a continuación, compruebe el tamaño de los archivos Tempdb.mdf y Templog.ldf.

Una limitación de este método es que sólo funciona en los archivos lógicos predeterminados tempdb, tempdev y templog. Si los archivos adicionales que se agregaron a tempdb, es posible reducir el tamaño después de reiniciar SQL Server como un servicio. Todos los archivos de tempdb se vuelvea crear durante el inicio, por lo tanto, están vacíos y se puede quitar. Para quitar los archivos adicionales de tempdb, utilice el comando ALTER DATABASE con la opción REMOVE FILE.

 

Método 2 para comprimir Tempdb

 

Utilice el comando DBCC SHRINKDATABASE para reducir la base de datos tempdb en su totalidad. DBCC SHRINKDATABASE recibe el parámetro, que es el porcentaje deseado de espacio libre que queda en el archivo de base de datos después de que la base de datos
es reducido. Si utiliza DBCC SHRINKDATABASE, puede que tenga que reiniciar SQL Server.

IMPORTANTE: Si se ejecuta DBCC SHRINKDATABASE, ninguna otra actividad puede estar ocurriendo con la base de datos tempdb. Para asegurarse de que otros procesos no puedan utilizar tempdb mientras se ejecuta DBCC SHRINKDATABASE, debe iniciar SQL Server en modo de usuario único.

1. Determine el espacio que tempdb utiliza actualmente mediante el procedimiento almacenado sp_spaceused. Luego, se calcula el
porcentaje de espacio libre que queda para su uso como un parámetro para DBCC
SHRINKDATABASE; este cálculo se basa en el tamaño de la base deseada.

Nota En algunos casos puede que tenga que ejecutar sp_spaceused @ updateusage = true para volver a calcular el espacio
utilizado y obtener un informe actualizado.

Considere este ejemplo:
Supongamos que

tempdb
  tiene dos archivos: el archivo de datos principal (Tempdb.mdf), que es de 100 MB de tamaño y el archivo de registro (Tempdb.ldf),
que es de 30 MB.

Supongamos que
sp_spaceused
  informa que el archivo de datos principal contiene 60 MB de datos. Suponga también que desea reducir el tamaño del archivo de datos principal de 80 MB. Calcular el porcentaje deseado de espacio libre que queda después de la compresión: 80 MB – 60 MB = 20 MB. Ahora, divida 20 MB por 80 MB = 25% y que es el porcentaje Destino. El archivo de registro de transacciones se redujo en
consecuencia, dejando el 25% o 20 MB de espacio libre después que la base de datos es reducida.

 

2.      
2. Conecte a SQL Server con el Analizador de consultas y ejecute los siguientes comandos Transact-SQL:

 

dbcc shrinkdatabase(tempdb, ‘target percent’)

– This command shrinks
the tempdb database as a whole

 

 

Existen limitaciones para el uso del comando DBCC SHRINKDATABASE en la base de datos tempdb. El tamaño de destino para los datos y archivos de registro no puede ser más pequeño que el tamaño especificado cuando se creó la base de datos o el último tamaño establecido explícitamente con una operación de cambio de tamaño de archivo como ALTER DATABASE con la opción MODIFY FILE o el comando DBCC SHRINKFILE. Otra limitación de DBCC SHRINKDATABASE es el cálculo del parámetro target_percentage y su dependencia del espacio utilizado actualmente

 

Método 3 para comprimir Tempdb

 

Utilice el comando DBCC SHRINKFILE para reducir el tamaño de los archivos de tempdb individuales. DBCC SHRINKFILE proporciona más flexibilidad que DBCC SHRINKDATABASE porque se puede usar en un archivo de base de datos única sin
afectar a otros archivos que pertenecen a la misma base de datos. DBCC SHRINKFILE recibe el parámetro de tamaño de destino, que es el tamaño final deseado para el archivo de base de datos.

IMPORTANTE: Usted debe ejecutar el comando DBCC SHRINKFILE, mientras que ninguna otra actividad se este produciendo en la base de datos tempdb. Para asegurarse de que otros procesos no puedan utilizar tempdb mientras se ejecuta DBCC SHRINKFILE, debe reiniciar SQL Server en el modo de usuario único.

 

1.      
Determine el tamaño deseado para el archivo de datos principal (tempdb.mdf), el archivo de registro (templog.ldf), y / o archivos adicionales agregados a tempdb. Asegurarse de que el espacio utilizado en los archivos es menor o igual al tamaño deseado.

 

2.      
Conecte a SQL Server con el Analizador de consultas y ejecute los siguientes comandos Transact-SQL para los archivos de base de datos específicos que se necesitan para reducir el tamaño:

 use tempdb

go

 

dbcc shrinkfile(tempdev, ‘target size in MB’)

go

– this command shrinks the primary data file

 

dbcc shrinkfile(templog, ‘target size in MB’)

go

– this command shrinks the log file, look at the last
paragraph.

 

Una ventaja de DBCC SHRINKFILE es que puede reducir el tamaño de un archivo a un tamaño más pequeño que su tamaño original. Puede emitir DBCC SHRINKFILE en cualquiera de los archivos de datos o archivos de registro. Una limitación de DBCC SHRINKFILE es que no se puede hacer que la base de datos sea más pequeña que el tamaño de la base de datos model.

En SQL Server 7.0 un registro de transacciones de contracción es una operación diferida y debe emitir un truncamiento de registro y copia de seguridad paraayudar a la operación de reducción en una base de datos. Sin embargo, por defecto, tempdb tiene la opción trunc log on chkpt establecido en ON, porlo tanto, hay que no es necesario emitir un truncamiento del registro de la base de datos.

 

 Efectos de la ejecución de DBCC SHRINKDATABASE o DBCCSHRINKFILE mientras Tempdb está en uso


Si tempdb está en uso y se intenta reducir su tamaño mediante el uso de la instrucción DBCC SHRINKDATABASE o comandos DBCC SHRINKFILE, puede recibir múltiples errores de consistencia similar a la siguiente tipo y la operación de reducción puede fallar:

Servidor: Mensaje 2501, Nivel 16, Estado 1, Línea 1 No se pudo encontrar la
tabla ’1525580473 ‘. Compruebe sysobjects.
-o-
Servidor: Mensaje 8909, Nivel 16, Estado 1, Línea 0 Tabla dañada: Id. de objeto 1, Id. de índice 0, Id. de la página% S_PGID.

El PageId
en el encabezado de página =% S_PGID.

Aunque el error 2501 no puede ser un indicio de daños en tempdb, hace que la operación de reducción fracase. Por otro lado, el error 8909 podría indicar la corrupción en la base de datos tempdb. Reinicie SQL Server para volver a crear tempdb y limpiar los errores de coherencia. Sin embargo, tenga en cuenta que podría haber otras razones para los errores de corrupción de datos físicos, como el error 8909 y los que se incluyen entrada / salida de los problemas del subsistema.

 

 

 

REFERENCIAS


SQL Server Books Online; topics: “DBCCSHRINKFILE”; “DBCC SHRINKDATABASE”

 

http://support.microsoft.com/?scid=kb;en-us;307487&x=9&y=13

 

Espero les sirva,   Saludos

http://dbasqlserver.wordpress.com/

 

2 comentarios

Tablas temporales versus Variables de Tabla


Originalmente publicado en Grimpi IT Blog:

Una duda bastante comun entre los desarrolladores que trabajan con SQL Server, es saber
distinguir entre una tabla temporal y una variable de tabla.
Ambas estructuras presentan varias diferencias importantes, y fueron hechas para resolver distintos problemas, aunque en muchas situaciones, su uso puede superponerse.
Veamos algunas características de las variables de tabla y sus diferencias con las tablas temporales:

1) Contra lo que muchos suponen, el contenido de una variable de tabla no siempre esta completamente en memoria. En caso de que se inserte una alta cantidad de registros a la variable, se almacenará en tempdb. En cambio una tabla temporal siempre se guarda en tempdb.
Además, cuando se crea una variable tabla, es como si se efectuara cualquier otra operación DDL, por lo tanto la información de la metada se guarda en las tablas de catalogo.
Veamos este código:

DECLARE @TablaTemporal TABLE (ID int)
SELECT * FROM tempdb.sys.tables

Ver original 638 palabras más

Deja un comentario

Diferencias entre Snapshot, LogShipping, Mirroring, Replication y Failover Clustering


Log Shipping, Snapshot, Instantanea, Mirroring, espejeo, Replicaction, Replicación Y Failover clustering.

Todos estos terminos de SQL SERVER  son temas confusos para algunos. Afortunadamente el ultimo sabado se presento una sesion por http://blogs.sqlxml.org/vinodkumar/ en  http://bdotnet.in/.  Asi que voy a tratar de transmitir de una manera simple la impresión que tengo ahora de estos terminos.

1) Snapshot Es una fotografia estatica de solo lectura de la base de datos en un punto del tiempo dado,  snapshot es implementado mediante la copia de una pagina (8kb en SQL Server) en un cierto punto del tiempo. Por ejemplo vamos a asumir que tienes una tabla en tu base de datos y tu deseas tomar una fotografia de ella,  por que te interesa saber como estaban tus datos en ese cierto periodo de tiempo, ya que sabes que con el pasod el tiempo ocurriran procesos que podrian dejar irreconocibles los datos que te servian en ese momento tal vez para analizar o generar algun reporte (Nota, tambien ahi algo llamdo snapshot isolation level el cual es un termino muy aparte de las snapshot de bases de datos).

Escenario donde se puede usar: Si tienes una base separada para generación de reportes, y deseas asegurar que la información mas reciente estara disponible,  puedes periodicamente tomar fotografias de tu base de datos transaccional y sacar el reporte de la snapshot.

2) Log Shipping es una vieja tecnica disponible desde SQL Server 2000. En este caso los logs de transacciones (ldf’s) son transferidos periodicamente a un servidor en stand by. Si el servidor activo va para abajo se puede subir el servidor en stand by restaurando todos los logs transferidos.

Escenario donde se puede usar: Si se dispone de una ventana mas flexible de tiempo en donde el tiempo de espera para tener la información mas actual puede tiene un alto grado de tolerancia, si tienes limitados los recursos en cuanto a compartimiento de storage, switches, etc, etc.

3) Mirroring esta tecnica fue introducia en la edicion 2005,  se puede decir que es la evolución del log shipping. La principal diferencia is el tiempo de espera para tener la información mas actual el espejeo es un recurso mas rapido que el log shipping. Otra diferencia es que el servidor en stand by automaticamente puede levantarse en caso  de que el servidor principal fallara (a esto se le llama espejeo de alta disponiblidad, y para esto requerimos de un tercer servidor al que nombran testigo), sin tener que restaurar los registros (en realidad, los registros se fusionan de forma continua en este escenario – no es de extrañar que se llama Espejo). Las ventajas adicionales incluyen la creación de reflejo de apoyo a nivel NET Framework (léase: failover / enrutamiento de código – requiere ADO.NET 2.0 y superior). Además de algunas nuevas características como la recuperación automática de páginas incluidas en SQL Server 2008.

periodicamente a un servidor en stand by. Si el servidor activo va para abajo se puede subir el servidor en stand by restaurando todos los logs transferidos.

Escenario donde se puede usar: si usted desea que el tiempo de recuperación sea menos y también requiere una solución rentable en términos de almacenamiento compartido, interruptores, etc También se dirigen a una base de datos única que se adapta fácilmente en sus discos.

4) Replication Es usado principalmente cuando los data centers se encuentran distribuidos geograficamente. Este es usado para para replicar datos desde servidores locales a un servidor principal en el data center central, una cosa importante a notar aqui es que no hay servidores en stand by, el publicador y el suscriptor ambos son servidores activos.

Escenario donde se puede usar: Un escenario típico consiste en la sincronización de los servidores de búsqueda locales / regionales para un mejor rendimiento con el servidor principal en el centro de datos de forma periódica, o sincronizarlo con un sitio remoto de recuperación de desastres.

5) Failover clustering es una opción de alta disponibilidad unicamente usado (a diferencia de las otras esta opción puede ser usado perfectamente como un plan para recuperación de desastres)  con tecnologia en cluster que incluye la cooperación del hardware y del sistema operativo.

Aquí los datos y bases de datos no pertenecen a ninguno de los servidores, y de hecho residen en almacenamiento compartido externo como SAN. Las ventajas de un dispositivo de almacenamiento SAN es de gran eficiencia de almacenamiento de disco.

Aqui os dejo un buen articulo que trata sobre failover en cluster. http://www.sqlskills.com/BLOGS/PAUL/post/Adding-geo-redundancy-to-failover-clustering.aspx

Tambien les aporto este link  con las caracteristicas de las ediciones y licenciamiento, ya que es un tema que tendrian que ver cuando se decidan por alguno de las opciones.

Espero les sirva

Fuentes:

http://nirajrules.wordpress.com/2008/12/08/snapshot-vs-logshipping-vs-mirroring-vs-replication/

1 comentario

Generar script de todos los jobs en SQLServer2000, SQLServer2005 y SQLServer2008


Te has visto en la necesidad de tener que generar los scripts de todos los jobs que tienes programados en tu instancia, esto podria ser sencillo si son pocos cierto, que pasa cuando son algunos cientos, pues aqui te dejo este post que te ayudara a generar de un salo jalon los scripts de todos los jobs que tienes en SQL Server para las versiones 2000, 2005 y 2008

Como generar el script para los jobs en SQLServer 2000

  • Expande un server group, y expande el servidor
  • Expande Management, y entonces expande SQL Server Agent
  • Clic  con el botón secundario  en jobs y después en Generate  SQL Script
  • Por último selecciona nombre de archivo, lugar de destino y tipo de archivo que quieres que se genere ,  yo en lo personal utilizo Windows Text (Ansi)
  • Opcionalmente puedes palomear la opción Replace Job if it exists,  esta opción borrara los jobs con los mismos nombres que encuentre en tu instancia.
  • En la opción TSQL batch separator, introduce un separador de transact sql batch

Como generar el script para los jobs en SQLServer 2005 y 2008

Ahora para las versiones posteriores a sql SERVER 2000 les voy a mostrar una forma sencilla de hacerlo aunque existe mas de una forma, esta me parece la menos complicada,

 

Primero que nada si lo que quieres es generar un archivo por cada  job que tengas el metodo es otro,  sigue este link que te muestra una forma de hacerlo: http://blogs.lessthandot.com/index.php/DataMgmt/DBAdmin/scripting-all-the-jobs-on-your-sql-serve

 

Si te quieres generar un solo archivo puedes seguir las siguientes instrucciones:

  • Entra a SQL Server management studio
  • Expande SQL Server Agent
  • Selecciona la carpeta JOBS
  • Oprime tecla f7 y te aparecera de lado derecho una lista detallada con los jobs
  • Ahora  podras seleccionar mas de un job a la vez con esto puedes seleccionar todos
  • Con todos los jobs seleccionados clic boton secundario, script job as, create to, file

 

Y listo el pollo  ya tienes tu script listo para que lo ejecutes en otro servidor o instancia, o tan solo para resguardar

 

 

Saludos espero les sirva

 

 

 

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 33 seguidores

%d personas les gusta esto: