Wednesday, 15 March 2017

Server backup




How to schedule a SQL Server backup


Having a good backup and restore plan is an important part of a disaster recovery strategy. This article will describe 3 different solutions/approaches for creating a scheduled backup in SQL Server
As a part of a backup strategy several types of backup can be used together.

Backup types

  1. Full database backups include all database objects, system tables, data, and transactions that occur during the backup. Full database backups allow performing a complete restoration to a state before the backup is performed.
  2. Differential backups contain data that has changed since the last full backup was performed and transactions that occur during the backup process. A differential backup is used alongside with the last full database backup. After taking a differential backup, as it is taken after the last full backup all of the old differential backups become obsolete.
  3. Transaction log backups records all the transactions that have occurred on a database since the previous transaction log backup and then truncates the transaction log and then truncates a transaction log. A transaction log backup ensures database recovery to a specific point of time e.g. to a moment prior to data loss.
  4. File and filegroup backups option is most suitable for backing up very large databases. A file backup will contain all the data in one or more files or filegroups. A transaction log backup has also be performed to span all the file backups from start to finish when using file backups to restore a database.
  5. Copy-only backups are mostly used when it’s needed to backup a database without affecting the processes of backup and restore for a specific database. Functionality of a copy-only backup is the same as full database with a difference that a transaction log backup will backup all transactions since the last full backup is performed and ignore the existence of the copy backup, therefore a copy backup cannot be used as the basis for differential and transaction log backups.

Recommended backup strategy practices

Backup location

It is advisable that backups are not stored on the same location (physical drive) where database files are stored. In cases when a physical drive fails use the drive or a network location to perform restore. If a file location is not specified when creating a database SQL Server will store database files on the default database locations.
Note that changing the default locations won’t move the current data and log files to a new location. This will only be applicable to databases created after this change.

Scheduled and automated backups

To prevent and backup safety and reliability is to set up (automate) the backup process through the means of schedules. Creating backup schedules is important as the time passes current backups get obsolete and out of time.
Keep yourself protected and be sure that you always have at hand a way to reestablish your data up until the point where the database failed. Scheduled backups provide an accurate data history.
The specified frequency of a backup depends on the company business needs etc., and is defined by Recovery Point Objective (RPO). For example, if an organization’s Service Level Agreement (SLA) specifies that no more than an hour’s data can be lost from a database, the RPO is one hour.

Test backups

Backup and recovery strategy cannot be complete until backups are successfully restored on a test server and verified that backup can be restored to fulfill all the requirements and conditions including all the combinations that the recovery strategy requires. There is a variety of factors to consider such as: the organizations requirements regarding the usage of data, protection etc.

Backup verification

Verifying backup ensures that a backup is created correctly, intact physically, that all the files in the backup are readable and can be restored in the event that the user needs to use it, and that all the transactions are consistent. It is important to understand that verifying a backup does not verify the structure of the data on the backup. However, if the backup was created using WITH CHECKSUMS, verifying the backup using WITH CHECKSUMS can provide a good indication of the reliability of the data on the backup.
By using T-SQL:
Including the CHECKSUM statement ensures consistency of data on the backup destination. To include CHECKSUM use the following query:
BACKUP DATABASE [AdventureWorks2012]
TO  DISK = N'F:\Backup\AW12.bak'
WITH CHECKSUM;
SQL Server Management Studio also provides options to include backup verification a CHECKSUM check when creating a backup as a task:
The Verify backup when finished option and Perform checksum before writing to media are used as an insurance that both backup and its data are consistent.
We will also show how to include verifications when scheduling backups.
In this article we will create a SQL Server scheduled backup by using a SQL Server Agent job, SQL Server Maintenance Plans, and ApexSQL Backup.

Create a SQL Server scheduled backup by using a SQL Server Agent job

To automate and schedule a backup with SQL Server Agent:
  1. In the Object Explorer pane, under the SQL Server Agent node, right click Jobs and select New job from the context menu:
  2. In the New Job dialog enter a job’s name
  3. Under the Steps tab click on the New button and create a backup step by inserting a T-SQL statement. In this case the CHECKSUM clause has to be included in T-SQL code:
    USE AdventureWorks2012
    GO
    BACKUP DATABASE [AdventureWorks2012]
    TO  DISK = N'F:\Backup\AW12.bak'
    WITH CHECKSUM;
    
    To create a differential backup use the following T-SQL script:
    USE AdventureWorks2012
    GO
    BACKUP DATABASE [AdventureWorks2012]
    TO  DISK = N'F:\Backup\AW12.bak'
    WITH CHECKSUM;
    
    
    BACKUP DATABASE [AdventureWorks2012]
       TO  DISK = N'F:\Backup\AWD12.bak'
       WITH DIFFERENTIAL;
       WITH CHECKSUM;
    
    GO
    
    To backup transaction log use the following script:
    BACKUP LOG [AdventureWorks2012]
       TO  DISK = N'F:\Logs\AWD12.log';
    GO
    
    Note: To create a differential or a transaction log SQL Server database backup a full database backup has to exist. If a desired database has never been backed up, before creating differential backups, first create a full database backup. Differential and transaction log backups can be used along a full database backup. For example, a full backup can be scheduled every 24 hours, a differential backup can be performed every 5 hours, and a transaction log backup every 15 minutes.
  4. Click ok to add a step, and click OK to create a job:
  5. To schedule a job, in the New Job dialog, under the Schedule tab click New.
  6. In the Job Schedule select an occurring frequency and a start date and click OK:
To check a created job in the Object Explorer pane and under the SQL Server Agent ➜ Jobs node right click the job create above and select the Start job at step option:
To use SQL Server Agent for backing up all databases under one instance there are two approaches, both of which require some manual work. One approach is to create a SSIS package using the Backup Database Task option from the SSIS toolbar and create a SQL Server Agent job to schedule it.
The other approach is to write a T-SQL script to backup all databases in the SQL Server Agent Job Step dialog.

Create a SQL Server scheduled backup by using SQL Server Maintenance Plans

There are two options to create a scheduled backup task by using SQL Server Maintenance Plans: manually by creating a new plan and by using the Maintenance Plan Wizard.
To manually create a scheduled backup task:
  1. In the Object Explorer pane under the Management node right click Maintenance Plans and select the New Maintenance Plan option:
  2. From the Maintenance Plan Tasks toolbox select Back Up Database Task:
    The Maintenance Plan Wizard also provides the Check database integrity task that can be included in Maintenance Plan:
  3. Double click on an added plan and set backup options:
  4. To schedule a SQL Server Agent job use the Sub plan scheduling option.
  5. When a plan is created click save and this action will create a corresponding job under the SQL Server Agent ➜ Jobs folder.
A method to create a new maintenance plan through the Maintenance Plan Wizard guides the user through the process, but this option provides fewer options for fine tuning.
To automate and schedule a backup by using the SQL Server Maintenance Plan Wizard:
  1. In the Object Explorer pane under the Management node right click Maintenance Plans and select the Maintenance Plan Wizard option:
  2. In the Select Plan Properties window specify a plan name. To schedule a SQL Server Agent job click the Change button:
  3. In the Select Maintenance Plan Tasks select the Back Up Database option and the Check data integrity option. The check data integrity tack performs internal consistency check of the data and index pages within the database :
  4. In the following window configure the maintenance task by specifying a database for backup and the backup options. In the Define Back Up Database Task window also check the Verify backup integrity option:
  5. After verifying the choices and actions click Finish:
Maintenance Plans are more suitable for less experienced DBAs because they provide an easy to use GUI, and do not require manually written maintenance scripts. The downside of Maintenance Plans is that the tasks that Maintenance Plans provide are basic and don’t leave space for customization.
A Maintenance Plan is also atomic and is therefore not able to run multiple tasks. Each type of maintenance task within a single Maintenance Plan can only be configured to run once within that Plan. For example, if a task that is made to delete older backup files it will only delete one file type at a time. Because of this multiple Maintenance Plans have to be created just to perform a single task, in some cases, and every Maintenance Plan has to have a corresponding SQL Server Agent job to be scheduled.

Create a SQL Server scheduled backup by using ApexSQL Backup

As we saw when scheduling a SQL Server backup as a SQL Server Agent job we have to write a T-SQL script. Also, to fulfil the organizations SLA we would have to make two more jobs, one for a differential and one for a transaction log job.
To save time from having to write T-SQL scripts and eliminate the need to maintain both back up plans and their corresponding jobs when using SQL Server Maintenance Plans, a 3rd party tool, ApexSQL Backup, can be used.
ApexSQL Backup is a SQL Server backup manager that enables automating and scheduling SQL Server backup jobs in one task while preserving the backup chain for easy point-in-time restoration (database rollback).ApexSQL Backup is also able to run multiple tasks at the same time and provides an out of the box solution for scheduling a database backup for one or all databases in just a few clicks.
To create a SQL Server scheduled backup in ApexSQL Backup:
  1. In the Home tab of the main menu select the Backup option:
  2. In the Backup wizard specify a server name, a database name, and a backup type. ApexSQL Backup supports all backup types and provides an option to select all databases:
  3. In the Type and output window specify a destination folder and an output name:
  4. In the Options window specify backup options such as backup verification, compression, encryption etc. ApexSQL Backup offers options to include both the Verify backup step when finished, and the Perform checksum step before writing to media option during the process of creating a backup task without the need for writing a separate script:
  5. In the following window select the Schedule option and specify the occurring frequency. ApexSQL Backup allows scheduling a backup task during the process of creating a task:
  6. Submit a scheduled backup.
Here’s a review of all three approaches to schedule a database backups:
SQL Server Agent
Maintenance Plans
ApexSQL Backup
T-SQL script needed
Yes
No
No
Can backup all databases without a script
No
Yes
Yes
Can execute a task without an additional job
Yes
No
Yes
Can run multiple tasks at once
No
No
Yes
Useful resources:

Export Data from AX 2012 - using DIXF (Data Migration Framework)

Importing is a well known task using DIXF, but at times we do need to export as well and then import it back in AX 2012. The export task can be done with the help of this information.

https://technet.microsoft.com/en-us/library/dn144987.aspx



Define the format of your source data


  1. Open Data Import/Export Framework > Setup > Source data formats.
  2. Click New, enter a name and a description, and then select AX from the Type list.

Define a processing group to export data from Microsoft Dynamics AX


  1. Change the company to CEU.
  2. In Data Import/Export Framework, click Common > Processing group, and then click New to create a new processing group.
  3. Set the group name to Export-Cust and add a description.
  4. Click Entities to select the entities to include in the processing group.
    1. In the Select entities for processing group form, click New, and then, for an entity name, select Customer.
    2. In the Source data format field, select the Microsoft Dynamics AX source data format that you created.
    3. Click the Select button, and then in the DMFCustomerTargetEntity form, on the Range tab, for Field, choose Created date and time, and for Criteria, enter > 9/1/2007, and then click OK.
    4. Close the Select entities for processing group form.

Process data from source to staging


  1. In the Processing group form, select the Export-Cust group that you created, and click Get staging data.
    The Create a job ID for the staging data job form opens.
  2. By default, an ID for the job is generated. If needed, you can modify the ID and add a description. Click OK.
    The Staging data execution form opens.
  3. In the Staging data execution form, click Run.
    The Get data from source to staging form opens.
  4. In the Get data from source to staging form, click OK to run immediately.
    The source data is copied to the staging tables.

Validate the data in staging


  1. In Data Import/Export Framework, click > Common > Processing group > Execution history, and then select the job that ran.
  2. Click View staging data.
  3. Review the staging data to validate that it matches the source.
  4. Click Validate all to verify that all the related reference data is correct and present in the system.

Export the data to a file


  1. In , click > Common > Processing group, and then select the processing group to work with.
  2. Click Export to AX, enter a file name, and then click OK.
    A .dat file of the data identified by the processing group is created.

Pass the parameter from one form to another in Dynamic AX

 Create two forms with Name FormA & FormB.

 FormA with 1 stringedit and 1 button & FormB with 1 StringEdit.

 Below code is override in clicked method() of button.

void clicked()
{
    // Args class is usually used in Axapta for passing parameters between forms
    Args            args;
    FormRun         formRun;
    ;
    args = new args();  
    // Our values which we want to pass to FormB
    // If we want pass just simple string we can use 'parm' method of 'Args' class
    args.parm( AccountNum.text() );
    // Run FormB
    args.name( formstr( FormB ) );
    formRun = classFactory.formRunClass( Args );
    formRun.init();
    formrun.run();
    formrun.wait();
    super();
}
 Now override init() method in FormB.
public void init()
{
    str             anyStringValueFromCaller;
    ;
    super();
    // Check for passed arguments
    if( element.args() )
    {
        // get string parameter
        anyStringValueFromCaller = element.args().parm();
        SelectedAccountNum.text(anyStringValueFromCaller);
    }
}