SQL Server Sandbox

Estoy tratando de configurar un entorno limitado para que nuestros desarrolladores de informes realicen su trabajo. Mi plan actual es "restablecer" la base de datos todas las noches, pero no estoy seguro de cómo hacerlo. Lo que quiero decir con reinicio es que quiero eliminar esencialmente cualquier tabla de usuario, vista, procedimientos almacenados, etc. de todas las bases de datos del servidor excepto una. Supongo que otra opción sería eliminar y volver a crear la base de datos también, pero estoy bastante seguro de que eso significaría volver a otorgar acceso a todos los grupos / personas AD apropiados también.

Realmente no sé cuál sería la mejor manera de hacerlo, así que espero que algunos de ustedes puedan proporcionar algunas buenas ideas / sugerencias. Gracias.

Para mayor claridad, esencialmente queremos hacer esto con nuestra base de datos: http://try.discourse.org/t/this-site-is-a-sandbox-it-is-reset-every-day/57 . La única diferencia es que no queremos recrear a nuestros usuarios todos los días.

Versión: SQL Server 2008
Edition: Developer & Enterprise

sql-server sql-server-2008 Kittoes0124
fuente

Respuestas:

Otra idea sería simplemente configurar un trabajo nocturno que haga una copia de seguridad copy_only y lo restaure en el servidor de desarrollo (o en el mismo servidor, si solo tiene uno, pero esa podría no ser una gran idea). Lo bueno de esto es que la restauración puede ir a cualquier servidor (o servidores múltiples), y puede ser completamente desacoplada de cualquier actividad en la base de datos primaria.

En el servidor 1:

BACKUP DATABASE db TO DISK = '\\someshare\file.bak' 
  WITH COPY_ONLY, INIT, COMPRESSION;

En el servidor 2:

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY;

Es posible que también deba agregar MOVEcomandos si el diseño del disco entre los servidores es diferente (o si coloca la copia en el mismo servidor).

RESTORE DATABASE db_dev FROM DISK = '\\someshare\file.bak'
  WITH REPLACE, RECOVERY,
  MOVE 'data_file_name' TO 'D:\somepath\somefile.mdf',
  MOVE 'log_file_name'  TO 'E:\somepath\somefile.ldf';

Si está restaurando en el mismo servidor, no debería tener ningún problema con los usuarios. Si restaura a un servidor diferente, sus usuarios existirán pero los inicios de sesión a nivel de servidor pueden no existir. Hay scripts para arreglar eso , y una nueva característica en SQL Server 2012 ( Bases de datos contenidas ) que elimina el problema por completo.

Aaron Bertrand
fuente

Tenemos dev / prod pero dev es el único servidor en el que esto sucedería. Prod es solo para procesos listos para producción.

Kittoes0124

Esta es la solución que elegiría, solo tenga en cuenta que en la mayoría de los casos no desea simplemente copiar la producción al entorno de desarrollo. Establezca una medida (¿script?) Que, por ejemplo, eliminará u ocultará las direcciones de correo electrónico de los usuarios, los detalles de contacto, etc. No desea que sus desarrolladores comiencen a enviar correos electrónicos accidentalmente a los usuarios.

zeroDivisible el

Como tiene una instancia con el motor Enterprise Edition, usaría instantáneas de la base de datos .

Esto le permitirá revertir rápida y fácilmente cualquier cambio realizado durante el día, sin tener que restaurar toda la base de datos.

Tenga en cuenta que si los desarrolladores planean hacer grandes cargas de datos (¿suena como si no lo fueran?), Entonces esto puede no ser apropiado.

Jon Seigel
fuente

¿Por qué no sería apropiado si estuvieran haciendo grandes cargas de datos? La nuestra podría cargar, digamos ... 8 millones de filas de 100 columnas de vez en cuando (incluso si "no deberían" ser), pero no necesariamente queremos evitar que lo hagan. Todo lo que realmente nos importa es que todo se nukes al final del día.

Kittoes0124

@Kittoes porque se debe mantener una instantánea cuando cambian los datos de origen. Debe extraer las páginas existentes de la fuente si la fuente cambia, para mantener la vista "antes". No lo hace hasta que cambian los datos de origen (una instantánea utiliza un archivo disperso que está vacío, excepto los deltas). Este mantenimiento puede llegar a ser bastante costoso. Vea cómo funcionan las instantáneas de la base de datos .

Aaron Bertrand

@AaronBertrand Ok, entonces, si la base de datos crece a 8GB durante un día, entonces, cuando se restaura la instantánea, se eliminarán todos los datos nuevos, pero la base de datos aún tendrá un tamaño de 8GB. ¿O estoy malentendido?

Kittoes0124

@Kittoes una instantánea es de solo lectura, por lo que solo podrá cargar nuevos datos en la base de datos de origen. Si agrega 8GB durante el día, no será visible para la instantánea. Cuando revierte / suelta la instantánea, la base de datos de origen todavía tendrá esos 8 GB de datos y se dimensionará en consecuencia. Si luego toma otra instantánea, los nuevos datos serán visibles. Si elimina 8 GB durante el día, se agregará a la instantánea.

Aaron Bertrand

@Kittoes si quiere deshacer la carga de datos de 8GB volviendo al punto en el que se tomó la instantánea, sí, debería devolver sus archivos de datos al tamaño que tenían (si realmente desea que los archivos sean pequeños nuevamente, por lo que puede crecer automáticamente más cuando cargue 8GB nuevamente mañana es otro problema). Pero no he probado ese escenario explícitamente. Y como se menciona en el artículo que mencioné, esto no es necesariamente infalible, ya que también depende de la confiabilidad del almacenamiento subyacente. Una copia de seguridad es una forma más segura de hacerlo.

Aaron Bertrand

Déjame agregar mis pocos centavos para ver si te ayuda:

En mi empresa, tenemos la misma situación que todas las noches los desarrolladores quieren actualizar las bases de datos que han estado utilizando durante todo el día. Esto significa que tenemos un conjunto de bases de datos que de Dev no se toquen - digamos que A y otro conjunto de bases de datos que son copia exacta A, pero lo hacen sus cosas, pero quieren que se actualizan cada noche - digamos que B . Esto sucede en 1 instancia de servidor único.

Lo que he implementado es un PROCESO DE RESTAURACIÓN NOCTURNA para lograr esto. A continuación se muestra cómo funciona:

Cree una tabla de controladores con una lista de bases de datos que debe restaurarse todas las noches (como ha mencionado).

Tabla: nightly_restore (OriginalDB, RestoreDB, backuplocation, enabled_YN, Results, PASS_FAIL)

Luego, puede escribir algunos TSQL que recorrerán la lista de bases de datos de la tabla anterior y luego realizar las restauraciones y registrar cualquier éxito o falla en los Resultados y un bit 1 = Pasar o 0 = Fallar. Enabled_YN determinará si esa base de datos necesita ser restaurada o no.

Si hay más bases de datos que se agregarán en el futuro, solo tiene que insertarlas en la tabla y establecer el bit enabled_YN en Y (habilitado).

De esta manera, el proceso será más flexible y manejable.

Si desea el SQL que he escrito (estoy seguro, podrá escribirlo :-)), solo envíeme un ping o agregue un comentario y lo compartiré.

HTH

Kin Shah
fuente