Estrategias de Backup

Existen organizaciones en donde los procesos de back-up no han sido modificados en años aunque los volúmenes de datos crecieran geométricamente.

Sin duda ha llegado el momento de que se reexaminen los requerimientos y recursos para respaldar y recuperar los datos.

Los editores de Enterprise IT Planet, medio de la familia de Datamation, consultaron a varios expertos para pedir diez consejos útiles en la mejora de estos procesos.

El primer consejo nos lo ofrece W. Curtis Preston, VP de GlassHouse Technologies Inc. y consiste en planificar en sentido inverso.

Esto equivale a partir de los requerimientos de recuperación: qué debe recuperarse y en cuánto tiempo. De esta manera, se fija el Recovery Time Objective (en qué tiempo debe restaurarse la data) y el Recovery Point Objective (qué tan actualizados deben ser los datos para cada clase de dato.)

El segundo consejo es el de salvar los archivos a disco antes de migrarlos a cintas. De esa manera, se achican las ventanas de back-up hasta en un 66%, economizando el uso de servidores y ahorrando tiempo de operación.

La tercer recomendación es la de eliminar el exceso de información a respaldar. No hace falta guardar copias diarias de archivos que no han cambiado en meses o copias de e-mails enviadas a varios empleados. La de-duplicación de archivos reduce la cantidad de espacio de storage y acelera los back-ups. Se han logrado reducciones de capacidad del orden de 20 a 1 usando de-duplicación de datos.

En cuarto lugar, se recomienda guardar las cintas de backup fuera de la zona de impacto de un eventual desastre y, si es posible, replicar o espejar los datos en un sitio de recuperación ante desastres lejano para que todo siga en línea si se cae el centro principal.


El quinto consejo tiene que ver con la eliminación de cuellos de botella en la red. Pueden demorar los procesos de backup y recuperación. Esto se hace más evidente con la virtualización de servidores donde múltiples servidores virtuales usan la misma interfaz y tarjeta de conexión a la red. Los drives de cinta pueden ser demasiado veloces para una interfaz de red, aunque ésta sea Gb Ethernet.

El sexto punto es minimizar la cantidad de productos de backup que se usan. Puede ser ventajoso usar a los mejores de su clase en cierto tipo de servidor, pero soportar varios productos puede ser complicado y costoso.

En séptimo lugar: usar varias capas de protección cuando sea adecuado. “Dependiendo de la criticidad y sensibilidad en tiempo de los datos, usamos diferentes métodos,” nos dice el gerente de operaciones de SunGard Availability Services, responsable por el backup de 30 TB de datos diarios. En algunos casos, usan múltiples soluciones para un mismo set de datos, como replicación remota combinada con backup en cintas.

Octavo: guardar una copia del plan de recuperación junto con el backup de los datos. Cuando ocurre un desastre, los que se ocupan normalmente de la operación pueden no estar disponibles. Con una copia del plan, alguien más puede ocuparse de las acciones necesarias.

En noveno lugar, está la conveniencia de probar el proceso de restauración completo y con el equipamiento que será usado en el caso de una emergencia. El sitio de recuperación ante desastres puede tener diferentes servidores o arquitectura de red. Si una aplicación busca una pieza de código o archivo en un servidor en especial ¿Qué ocurrirá si está en un servidor diferente? Prueben todo el sistema y no sólo si los archivos se recuperan adecuadamente.

Por último, queda la sugerencia de dejar la restauración rutinaria de archivos como función del help-desk para casos de archivos Word borrados accidentalmente, etc. De esta manera, los especialistas en storage pueden trabajar en la mejora de los niveles de servicio y atender al crecimiento y la flexibilidad de la operación.

Fuente:
Revista Datamation
www.datamation.com.ar

Implementando Disaster Recovery

Modelos de Recuperación (Recovery Models)

El Modelo de Recuperación 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).

Tipos de Modelos

-          Simple Recovery

-          Full Recovery

-          Bulk-Logged Recovery

Modo de Recuperación Simple o Sencillo (Simple Recovery Model).

·         Las Operaciones de Registro Mínimo realizarán un registro mínimo en el LOG de SQL Server, minimizando las escrituras en LOG y maximizando el Rendimiento de SQL Server.

·         Sólo se permiten Copias de Seguridad Completas o Diferenciales.

·         No se puede recuperar (RESTORE) a un punto en el tiempo (STOPAT).

·         Los cambios desde el ultimo backup están desprotegidos

·         ALTER DATABASE Demo SET RECOVERY SIMPLE

Cuando usar Simple Recovery

1.       Cuando un punto de recuperación no es necesario

2.       Quieres mejorar el desempeño

 Modo de Recuperación Completo (Full Recovery Model).

·         Las Operaciones de Registro Mínimo no se comportarán como tal, realizándose siempre un registro completo en el LOG de SQL Server.

·         Se permite cualquier tipo de Copia de Seguridad (BACKUP): Completas, Diferenciales, de Fichero, de Grupo de Ficheros (FILEGROUP), y de LOG.

·         Es posible recuperar (RESTORE) a un punto del tiempo (STOPAT).

·         ALTER DATABASE Demo SET RECOVERY FULL

Cuando usar Full Recovery:

1.       Si debes poder recuperar todos los datos

2.       Si debes poder recuperar un punto en el tiempo

§  Si estás dispuesto a incurrir los costos de administración del Log de Transacciones

3.       Si estás dispuesto a incurrir en el desempeño.

 Modo de Recuperación de Registro Masivo (Bulk-Logged Recovery Model).

Este Modo de Recuperación sólo debe ser utilizado de forma intermitente o eventual para mejorar el rendimiento de las Operaciones de Registro Mínimo.

·         Las Operaciones de Registro Mínimo realizarán un registro mínimo en el LOG de SQL Server, minimizando las escrituras en LOG y maximizando el Rendimiento de SQL Server.

·         Se permite cualquier tipo de Copia de Seguridad (BACKUP): Completas, Diferenciales, de Fichero, de Grupo de Ficheros (FILEGROUP), y de LOG,

·         No se puede recuperar (RESTORE) a un momento en el tiempo (STOPAT).

·         ALTER DATABASE Demo SET RECOVERY BULK_LOGGED

Cuando usar Bulk-Logged Recovery:

1.       Si estas corriendo cargas de datos masivos a gran escala,  y no requiras recuperación un punto de recuperación en el tiempo.

2.       Si corres periódicamente operaciones de carga masiva de datos.

3.       Si quieres conservar espacio en el disco usando mínimo LOG.

Tan pronto cuando tus operaciones de carga de datos haya finalizado,  inmediatamente regresa al modo de recuperación Full Recovery Model

Backup Types

Full Backup: Backup de toda la base de datos.

Diferential: Backup de los cambios efectuados desde el último Full Backup.

Transaction Log: Contiene todos los cambios desde el último backup de log. El backup de Log tiene, por defecto, la característica de que, una vez finalizado, dispara automáticamente una   operación de TRUNCATE sobre la log, lo cual libera su espacio utilizado. Sólo es posible bajo los modelos de recuperación Full y Bulk-Logged.

Demo

1.      Verifiquemos la ultima fecha de respaldo de nuestra base “Demo” y de su Log.   En las propiedades de la base de datos. Sección General.

2.      Crear un respaldo de la base de Datos,  de tipo Full Backup.

3.      Crear un respaldo del Log de la base de Datos.  

4.      Verificar nuevamente las fechas de respaldo de nuestra base.

5.      Ahora vamos a suponer que tenemos un caso de emergencia, tenemos corrupción en los datos, o cualquier otro problema con nuestra base.

6.      Vamos a respaldar la base,  seleccionamos el tipo de backup Transaction Log. En la sección de opciones,  apartado de Transaction Log, seleccionamos “Back up the tail of the log, and leave the database in restoring state”

7.      Ahora nuestra base de datos quedo en modo de “restoring”.

8.      A continuación vamos a recuperar nuestra base basado en el último backup que realizamos.  Click Derecho sobre la base, Task, Restore, Database

9.      Seleccionamos todos los respaldos que tenemos,  Full Backup, Transaction Log y Transaction Log (Read Only)

10.  Una vez hecho esto hemos recuperado nuestra base desde el ultimo Full Backup realizado.

11.  Vamos a modificar algunos datos de nuestra base para posteriormente recuperarla en un punto del tiempo.  Supongamos que por error ponemos todos nuestros productos en precio 0.

UPDATE Productos SET Precio  = 0

12.  Ahora procedemos a realizar un Backup Transaction Log y dejamos la base en recuperación como en el punto 6.

13.  Cerramos todas las conexiones a la base debido a que vamos a restaurarla,   seleccionamos todos los archivos de backup y escogemos un punto en el tiempo en la opción “To a Point in Time”, que tiene que ser antes que pasara nuestro error de productos  con precio 0.  Cabe recalcar que no hemos hecho ningún respaldo desde que nuestro backup inicial,  se restaurara basado en el Log de transacciones.

Guia Práctica Configurando Seguridad en SQL Server

Logins y Users

Logins están asociados a un servidor.

Users están asociados a una base de datos

Guia Práctica

1.       Crear un usuario de Windows llamado  Maria

2.       Abrir el MS Management Studio

3.       Buscamos en el Explorador de Objetos,  la Carpeta Security, Logins.

Aquí vamos a definir un nuevo Login,  el cual tendrá acceso al Servidor pero no a una base específica.

4.       Nuevo Login. Search.  Escribimos el nombre de nuestro usuario “Maria”.  Comprobamos.   Finalmente Aceptar

5.       Buscamos nuestra Base de Datos “Demo”.  Folder Security.  Folder Users.  Nuevo User.

6.       Aquí  vamos a definir el nombre del User, que puede ser o no el mismo del Login.   Escribimos Maria  y buscamos el Login equivalente.  Click en OK

  

7.       Iniciemos sesión de Windows con el Login Maria.

8.       Verifiquemos que no tenemos acceso a otras bases más que a “Demo”,  adicional no podemos visualizar ninguna Tabla,  solo vistas, pero al ejecutarla nos regresaran 0 Registros.

9.       Regresemos a la sesión de Administrador y  asignemos Roles al User Maria.    Vamos a la Base de Datos “Demo”.  Users y buscamos a “Maria”.  Asignaremos db_datareader y db_datawriter.

10.       Nuevamente regresamos a la sesión de Windows “Maria”.  Y verificamos los cambios.  Podemos ver las Tablas.  Y  Podemos hacer consulta de búsqueda e inserción de datos.

11.       En la sesión Administrador.  Buscamos el user “Maria” y vamos a la sección Securables.

Los Securables o “Asegurables” nos van a dar la opción de asignar permisos al usuario a determinados objetos y determinadas acciones.

12.       En securables seleccionamos Search,  “All Objects of the types”,  “Tables”.   Por ejemplo:  Para tabla Productos definimos que no tendra permisos para borrar.

13.       Regresamos a la sesion “Maria” y verificamos esta accion.

Roles

Cuando hablamos de Roles en SQL Server,  tenemos 2 Categorías:    Server-Level Role  y  DataBase-Level Role

Función de nivel de servidor	Descripción
sysadmin	Pueden realizar cualquier actividad en el servidor.
serveradmin	Pueden cambiar las opciones de configuración en el servidor y cerrar el servidor.
securityadmin	Administran los inicios de sesión y sus propiedades. Administran los permisos de servidor GRANT, DENY y REVOKE. También administran los permisos de base de datos GRANT, DENY y REVOKE. Asimismo, pueden restablecer las contraseñas para los inicios de sesión de SQL Server.
processadmin	Pueden finalizar los procesos que se ejecutan en una instancia de SQL Server.
setupadmin	Pueden agregar y quitar los servidores vinculados.
bulkadmin	Pueden ejecutar la instrucción BULK INSERT.
diskadmin	Se utiliza para administrar archivos de disco.
dbcreator	Pueden crear, modificar, quitar y restaurar cualquier base de datos.
public	Cada inicio de sesión de SQL Server pertenece a la función pública de servidor. Cuando a una entidad de seguridad de servidor no se le han concedido ni denegado permisos específicos para un objeto protegible, el usuario hereda los permisos concedidos a la función pública para ese elemento. Solo asigne los permisos públicos en cualquier objeto cuando desee que el objeto esté disponible para todos los usuarios.

 
 

Database-level Role

Función de nivel de base de datos	Descripción
db_owner	Pueden realizar todas las actividades de configuración y mantenimiento en la base de datos y también pueden quitar la base de datos.
db_securityadmin	Pueden modificar la pertenencia a funciones y administrar permisos. Si se agregan entidades de seguridad a esta función, podría habilitarse un aumento de privilegios no deseado.
db_accessadmin	Pueden agregar o quitar el acceso a la base de datos para inicios de sesión de Windows, grupos de Windows e inicios de sesión de SQL Server.
db_backupoperator	Pueden crear copias de seguridad de la base de datos.
db_ddladmin	Pueden ejecutar cualquier comando del lenguaje de definición de datos (DDL) en una base de datos.
db_datawriter	Pueden agregar, eliminar o cambiar datos en todas las tablas de usuario.
db_datareader	Pueden leer todos los datos de todas las tablas de usuario.
db_denydatawriter	No pueden agregar, modificar ni eliminar datos de tablas de usuario de una base de datos.
db_denydatareader	No pueden leer datos de las tablas de usuario dentro de una base de datos.

Schemas

Los esquemas facilitan un espacio de nombres (namespace), por lo que también nos permitirán organizar y agrupar nuestros objetos  y también facilitan la configuración de seguridad (GRANT, DENY, REVOKE) al poder conceder permisos sobre todos los objetos contenidos en un esquema mediante una única instrucción. 

1.       Crear dos esquemas

CREATE SCHEMA VENTAS

GO

CREATE SCHEMA RH   

2.       Crear Tablas y asignárselas al esquema RH

CREATE TABLE [RH].[Beneficios](

   [abc] [int] NULL

)

GO

CREATE TABLE [RH].[Deducciones](

   [abc] [int] NULL

)

GO

CREATE TABLE [RH].[Empleado](

   [abc] [int] NULL )

3.       Transferir el Esquema Ventas a la Tabla Clientes

ALTER SCHEMA Ventas TRANSFER dbo.clientes

4.       Crear una  nueva tabla llamada Flores y que pertenezca al esquema ventas.  Luego realizar la importación de datos desde un archivo CSV dado por medio de la sentecia BULK.

CREATE TABLE [Ventas].[Flores](

FlorID varchar(10) ,

      Nombre varchar(50) NULL,

      ColorPrimario varchar(50) NULL,

      ColorSecundario varchar(50) NULL,

      Medida varchar(50) NULL,

      Temperatura varchar(50) NULL,

      Costo smallmoney NULL,

      Precio smallmoney NULL,

      StockMinimo varchar(50) NULL,

      ProximaCompra varchar(50) NULL,

      Descripcion varchar(150) NULL)

GO

BULK

INSERT Ventas.Flores

        FROM 'c:\SQLServer\DatosFlores.csv'

            WITH

                ( FIELDTERMINATOR = ',',  ROWTERMINATOR = '\n' )

GO

5.       Creamos e Logins llamados:   Vendedor,  RecursosHumanos y AdminDemo.  Con Autenticacion SQL Server.  Password: 123.  Quitamos “Enforce Policy Password” para que nos deje guardar la contraseña sencilla.  En todos los casos ponemos por defecto la base de “Demo”

6.       En User Mapping,  seleccionamos la base “Demo” y buscamos el schema y asignamos al usuario correspondiente.  En el caso de AdminDemo no le asignamos uno específico porque tendrá accesos a muchos.

7.       Ahora vamos crear un Rol para Ventas, V_VENTAS,  V_RECURSOSHUMANO y asignarlo por esquema y a cada usuario.  

En la carpeta Security. Roles. DataBase Roles.

 

8.       Para el usuario AdminDemo  vamos a editar el rol db_owner y agregamos el usuario a este Rol.

9.       Ahora vamos a probar a cada usuario con un nueva conexión de sql por cada uno de ellos y ver las diferencias.  Podremos ver que cada usuario solo tiene acceso a la base Demo,  y específicamente a las tablas de su esquema.

XML en Plataforma .NET

View more presentations from brobelo.

Gestion de Tablas Particionadas

Un desafío para un diseñador de base de datos es diseñar sistemas que sean mantenibles, escalables y que tengan un buen desempeño.

Aunque el objetivo suena obvio,  algunas veces es difícil de lograr.

Una técnica  usada para intentar lograr un balance razonable entre  mantenimiento y escalabilidad vs. Desempeño  es las Tablas Particionadas.

 Esto no es nuevo, fue un cambio significante en SQL Server 2005 y continua en SQL Server 2008 proveyendo herramientas para ayudar a los desarrolladores a lograr esta tarea.

¿Por qué particionar?

El particionamiento divide grandes cantidades de datos en pequeños y más manejables sets.

¿Como ayuda?

 Modificar y buscar datos en un conjunto más pequeño es más fácil y rápido que trabajar con un gran set de datos.

Por ejemplo: Buscar  una factura por una fecha dada es más eficiente cuando buscamos en un archivador organizado.  Lo mismo sucede cuando buscamos en las tablas.

Beneficios:

Más rápido y eficiente acceso a datos.

El desempeño incrementa para operaciones en paralelo con servidores multiprocesadores,  cada procesador puede acceder a multiples particiones simultáneamente.

Nota:

Particionamiento de tablas e índices solo está disponible en SQL Server 2008 Enterprise, Developer y Ediciones de Evaluacion.

Terminos a Considerar

Partition Key:  Una columna en una Tabla determina a cual partición los datos residirán

Partition Function :  Una función que especifica que datos iran a que partición definidos por el Partition Key.

Partition Schema: Mapea una partición a un Filegroups.

Limites LEFT y RIGHT

Una función para 4 particiones:

 

Aquí lo que significa:

 

-- Crear una funcion de particion

CREATE PARTITION FUNCTION VentasxQuarterPF(datetime)

AS RANGE RIGHT

FOR VALUES ('19960101', '19960401', '19960701', '19961001')

GO

-- Filegroup para ventas < 01/01/1996

ALTER DATABASE Demo

ADD FILEGROUP Ventas1995Q4FG

GO

-- -- Filegroup para ventas >= 01/01/1996 AND <= 03/31/1996

ALTER DATABASE Demo

ADD FILEGROUP Ventas1996Q1FG

GO

-- Filegroup para ventas >= 04/01/1996 AND <= 06/30/1996

ALTER DATABASE Demo

ADD FILEGROUP Ventas1996Q2FG

GO

-- Filegroup para ventas >= 07/01/1996 AND <= 09/30/1996

ALTER DATABASE Demo

ADD FILEGROUP Ventas1996Q3FG

GO

-- Filegroup para ventas >= 10/01/1996 AND <= 12/31/1996

ALTER DATABASE Demo

ADD FILEGROUP Ventas1996Q4FG

GO

-- Para futuro crecimiento, adicionar un Filegroup

ALTER DATABASE Demo

ADD FILEGROUP Ventas1997Q1FG

GO

Creando archivos para los FileGroup

-- Ventas2002Q4FG filegroup

ALTER DATABASE Demo

ADD FILE(NAME = Ventas1995Q4,

    FILENAME = 'C:\SQL Server\Ventas1995Q4.ndf')

TO FILEGROUP Ventas1995Q4FG

GO

-- Ventas1996Q1FG filegroup

ALTER DATABASE Demo

ADD FILE(NAME = Ventas1996Q1,

    FILENAME = 'C:\SQL Server\Ventas1996Q1.ndf')

TO FILEGROUP Ventas1996Q1FG

GO

-- Ventas1996Q2FG filegroup

ALTER DATABASE Demo

ADD FILE(NAME = Ventas1996Q2,

    FILENAME = 'C:\SQL Server\Ventas1996Q2.ndf')

TO FILEGROUP Ventas1996Q2FG

GO

-- Ventas1996Q3FG filegroup

ALTER DATABASE Demo

ADD FILE(NAME = Ventas1996Q3,

    FILENAME = 'C:\SQL Server\Ventas1996Q3.ndf')

TO FILEGROUP Ventas1996Q3FG

GO

-- Ventas1996Q4FG filegroup

ALTER DATABASE Demo

ADD FILE(NAME = Ventas1996Q4,

    FILENAME = 'C:\SQL Server\Ventas1996Q4.ndf')

TO FILEGROUP Ventas1996Q4FG

GO

--  filegroup adicional

ALTER DATABASE Demo

ADD FILE(NAME = Ventas1997Q1,

    FILENAME = 'C:\SQL Server\Ventas2004Q1.ndf')

TO FILEGROUP Ventas1997Q1FG

GO

-- Crear un partition scheme usando un file group diferente para cada particion

-- NOTE: Ventas1997Q1FG es una particion extra.  SQL la marcara como NEXT used

CREATE PARTITION SCHEME VentasxQuarterPS

AS PARTITION VentasxQuarterPF

TO (Ventas1995Q4FG, Ventas1996Q1FG, Ventas1996Q2FG,

    Ventas1996Q3FG, Ventas1996Q4FG, Ventas1997Q1FG)

GO

Crear la tabla donde se utilizara las particiones

CREATE TABLE FacturasPT(

       [Codigo_Pedido] [int] NOT NULL,

       [Codigo_Cliente] [varchar](20) NULL,

       [Fecha] [datetime] NULL,

       [Origen] [varchar](50) NULL,

       [Descripcion] [varchar](max) NULL,

       [Total] [money] NOT NULL)

       ON VentasxQuarterPS(Fecha)

      

      

            

       INSERT INTO FacturasPT

       SELECT p.Codigo_Pedido, p.Codigo_Cliente, p.Fecha, p.Origen, p.Descripcion, p.Total

         FROM Pedidos p

      

SET STATISTICS IO ON

SELECT * FROM FacturasPT p

SELECT p.Codigo_Cliente, p.Total, p.Descripcion FROM Pedidos p

----  INFORMACION DE LA PARTICION

SELECT

  $PARTITION.VentasxQuarterPF(Fecha) AS Partition,

  COUNT(*) AS NumeroVentas

FROM FacturasPT

GROUP BY $PARTITION.VentasxQuarterPF(Fecha)

ORDER BY PARTITION

SELECT DISTINCT Fecha,

    $PARTITION.VentasxQuarterPF(Fecha) AS Partition

FROM FacturasPT

WHERE Fecha IN('19960115', '19960627',

    '19960817', '19971105')

ORDER BY Fecha

SELECT name, data_space_id, type, function_id

FROM sys.partition_schemes

-- Diplay information about partition filegroups

SELECT name, data_space_id, type

FROM sys.data_spaces