Las Copias de seguridad en SQL Server

Estructura de los ficheros en el SQL (mdf, ndf, ldf) Tabla de contenido Estructura de los ficheros en el SQL (mdf, ndf, ldf) Necesidad del Transacción LOG Modelo de Recuperación Tipos de las copias de seguridad Live Demo La copia de seguridad Manual / Reducir Log - La copia de seguridad Automática / Reducir Log

Estructura de los ficheros en SQL Server Software overview Estructura de los ficheros en SQL Server Primary data files Primary data file is the starting point of the database. It points to the other files in the database. Therefore, every database has one primary data file. Also, all the data in the database objects (tables, stored procedures, views, triggers.. etc.) are stored in the primary data files. The recommended and the most common file name extension for primary data files is .mdf. Secondary data files You can only have one primary data file for a database. Rest made up by secondary data files. But its not necessary to have a secondary data file. Therefore some databases may not have any secondary data file. But its also possible to have multiple secondary data files for a single database. .ndf is usually recommended to denote secondary data files. It’s also possible to store the secondary data file in a separate physical drive than the one which primary data file is stored. Log files Log files in SQL Server databases hold all the log information. Those information can be later used to recover the database. Size of the log file is determined by the logging level you have set up on the database. There must be at least one log file for each database. But it is also possible to have more than one log file for a single database. The recommended file name extension for log files is .ldf. The *.ndf files are used for secondary data files that make up all the data files, other than the primary data file. Secondary data files are used with extra large databases and often are stored on other hard drives, than primary database files (*.mdf files). Some databases may not have any secondary data files, while others have several secondary data files. If, after a start, the database is found in an inconsistent state (The consistency property ensures that any transaction will bring the database from one valid state to another. Any data written to the database must be valid according to all defined rules, including but not limited to constraints, cascades, triggers, and any combination thereof.) or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions. Additionally, all transactions that are already committed but whose changes were not yet materialized in the database are re-applied. Both are done to ensure atomicity and durability of transactions.

Necesidad de Transaccion Log https://www.youtube.com/watch?v=pezjufjUmFk

Modelo de recuperacion de la base de datos Recovery Model Simple Recovery Model Full Recovery Model Bulk recovery mode In full recovery model all the transacion are logged and unless you have a periodic transacional backups , the committed transaction are still there in the log file. this makes it to grow until you perform a log backup. Log backup takes all the committed transaction into in. Sonce you have all the transaction int he log you can recover the database up to the point in case of disaster. Simple recovery model save only the uncommited transaction in the log. the committed transaction are removed upod a checkpoint ussued by SQL Server. So log file never grows abnormally and you cannot perform a log backup. Point in time recovery is not possible in this case. If you have a full backup scheduled we can recover unly up to that point (NOT RECOMMEDED NORAMLLY) Bulk recovery mode: The bulk-logged recovery model is intended strictly as an adjunct to the full recovery model. We recommend that you use it only during periods in which you are running large-scale bulk operations, and in which you do not require point-in-time recovery of the database. Under this recovery model, most bulk operations are only minimally logged. If you use the full recovery model, you can switch temporarily to the bulk-logged recovery model before you perform such bulk operations.

Tipos de copias de seguridad Estrategia de la Copia de seguridad Depende del modo de recuperación: - Seleccionar modelo de recuperacion apropiado - Seleccionar tipo de copia de seguridad Depende del tamaño del fichero y el proceso de la copia: http://www.youtube.com/watch?v=5xA-6s8B7JA&list=PL4998438A07650FEF&index=50&feature=plpp_video

Tipos de las copias de seguridad Completa - Todos los ficheros de datos y las Transacciones del logs Permite recuperar los datos en el momento en el que la copia se estaba haciendo Más lento Más largo al restaurar Necesario para todos los tipos de seguridad http://www.youtube.com/watch?v=5xA-6s8B7JA&list=PL4998438A07650FEF&index=50&feature=plpp_video Allows recovery to the time the backup was performed Slowest Backup Type Longest to restore Base for all backup types

Tipos de las copias del seguridad Differential: Basado en la última copia completa Guarda solo los datos que se han cambiado desde la ultima copia completa Necesita una correcta copia completa y la copia differential para recuperar datos Más rápido que la copia completa Based on the last full backup Only data that has changed since the last full backup Requires a good full backup to recover data Faster backup time than full backup, Requires full backup and last differential backup for restoration

Tipos de las copias del seguridad Transacción Log Copia las Transacciones desde la base de datos Incluye los registros no copiados en la última copia de logs Limpia datos de transacciones desde su fichero de transacciones. Incluye Includes records not backed up in previous log backup Clears the backed up data from the Transaction Log (!! Simillar to incremental difference in ??) Back up the transaction log file to make most of the active virtual log files inactive. Therefore, the inactive virtual log files can be removed in a later step. To do this, start SQL Server Management Studio and then run a Transact-SQL statement that resembles the following Transact-SQL statement. BACKUP LOG <DatabaseName> TO DISK = '<BackupFile>' Note In this statement, <DatabaseName> is a placeholder for the name of the database that you are backing up, and <BackupFile> is a placeholder for the full path of the backup file. For example, run the following Transact-SQL statement. BACKUP LOG TestDB TO DISK='C:\TestDB1.bak' Shrink the transaction log file. To do this, run a Transact-SQL statement that resembles the following Transact-SQL statement. DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

No dudes en preguntar ¿Preguntas? sistemas@grupoactive.es www.grupoactive.es