Metadata Backup and Restore - Oracle 11g

As far as the ASM ecosystem is concerned,there isn’t much to back up.The only files that can be backed up are the initialization file or the spfile depending on the database standards for the company.Possibly,the $ORACLE_BASE/diag directory may need to be backed up if you are interested in preserving the log files.

Oracle Database 11g provides the capability to back up the ASM diskgroup structure and attributes including ASM aliases,directories,or templates.In Oracle Database 10g, objects such as aliases, directories,or templates have to be manually re-created after the restore. Prior to Oracle Database 11g,ASM metadata for the diskgroups could not be backed up because the metadata resides on the disk headers. We recommend that DBAs utilize the ASM Metadata Backup and Restore (AMBR) utility coupled with a solid RMAN backup strategy to provide the complete database recovery solution.Using the AMBR tools, you can protect the diskgroup structures since AMBR tools provide the facility to back up and restore the original ASM diskgroup with the same template and alias directory structures .Oracle Database 11g introduces AMBR’s md_backup and md_restore commands to provide a comprehensive level of protection for the ASM environment. Extensions to the asmcmd utility provide this extra level of protection for ASM:

  • md_backup [-o <backup_file_path> ] [-g diskgroup_name [-g diskgroup_name …]]
  • md_restore [ -t full|nodg|newdg]-fi <backup_file> -g dgname [-g dgname] [–o <override>] [-of <override_file>][-i] [-l< log_file>]

Backup Diskgroup Using md_backup

The md_backup command captures information about ASM disks,diskgroup and failure group configurations,and template and alias directory structures,and it creates a user-designated backup text file.

The md_restore command uses this text file and converts it into SQL commands to restore the custom user-defined metadata for the diskgroups.You can view the ASM alert log file to see the SQL generated by the md_restore command.We’ll provide an example of this in the next section when we demonstrate a complete ASM diskgroup backup and recovery.

With the md_backup command, users have the option to back up one or more diskgroups.The diskgroup names are delimited by commas.By default,the MDB file is created in the current working directory.This can be overwritten by providing a fully qualified file name.Not specifying the diskgroup(s) to the md_backup command will,by default,build metadata information for all diskgroups that are mounted.

Because the MDB file is a text file, users will be tempted to modify this file.You should be extremely cautious when modifying this file because ASM does not validate the syntax or accuracy of the flat file.

The md_restore command simply converts this file into SQL statements and executes it.Please back up this file before making any modifications to it.Having said all this, modifying the MDB backup file can be very useful.You can manipulate this file so that only certain ASM objects are restored instead of restoring the entire diskgroup.

You will see in the “Metadata Backup and Restore Demonstration” section that the MDB file has four distinct sections: disk information,diskgroup information,alias information,and template information.This tag is used by the md_restore command to locate the section in the backup file.

Backup Diskgroup Using md_backup

In the disk section of the MDB file labeled as DISKSINFO, information about diskgroup name, disk label name,disk path, OS size/ASM size of the disk,and failgroup name will be captured. For the diskgroup section labeled as DGINFO, characteristics of the diskgroup name,redundancy type, ASM/RDBMS compatibility,and AU size will be captured.

For the alias direction information section labeled as ALIASINFO,the MDB file has information about the diskgroup name,directory level, and alias name with the full path of the alias entry. Lastly, the template section labeled as TEMPLATEINFO houses relevant information for all system and nonsystem (user-defined) templates.For each template, the diskgroup name, template name, redundancy,stripe, and system designator is stored. All of this information is pertinent to the md_restore command.

Restore Diskgroup Using md_restore

The md_restore command of asmcmd performs an ASM metadata restore for adiskgroup.This utility reads the MDB backup file and essentially builds the required SQL statements to rebuild all the components of the diskgroup including templates, aliases, directories, and diskgroup names. This utility restores only the ASM diskgroup metadata information. Coupled with RMAN, you can achieve a higher level of data protection.You must still have a good RMAN backup.After a successful restore of the ASM diskgroup metadata,you can restore the database using RMAN.

This utility has several options.It can be used to restore the MDB backup file as is, or it can perform transformations of the diskgroup name. At the same time,you have the option to restore just one diskgroup or multiple diskgroups or all the diskgroups specified in the backup file.

Most important,the md_restore command will re-create all user-defined templates.It will also generate all the system templates and ASM alias directories including user-created directories.

md_restore -b <backup_file> [-li]
[-t (full)|nodg|newdg] [-f <sql_script_file>]
[-g '<diskgroup_name>,<diskgroup_name>,...']
[-o '<old_diskgroup_name>:<new_diskgroup_name>,...']

Now we’ll explain what some of these options mean.First, the -t option specifies the type of restore to be performed.The full tag specifies that all the diskgroups should be re-created using the same configuration from the MDB backup file.

The nodg option can be used to skip the diskgroup creation and just restore the metadata in an existing diskgroup provided as an input parameter.The newdg option can be used to allow the user to change disk specification/ failure group specification/diskgroup name/AVD file specification, and so on.

Obviously,the -f option specifies the backup file created by the md_backup command.Another important option is the -o option for override.This option can be used only in conjunction with the newdg option.

The override option allows the user to remap the diskgroup name,disk name, paths, and failure groups.An example of such an override option is in the form DGNAME=DATA:DATA_NEW, where the old diskgroup name is specified followed by a colon followed by the new designated diskgroup name. Another important option to note is the -i option to ignore errors.By default,the md_restore command aborts when it encounters an error.Lastly, the -l option can be used to log all messages to a log file.

Metadata Backup and Restore Demonstration

Now we’ll show how to perform a complete backup of ASM metadata.To demonstrate AMBR’s capability to back up and restore all the metadata pertaining to a diskgroup, we’ll simulate all the potential elements of the diskgroup including custom directories, templates, and aliases.After the backup is complete,a diskgroup will be dropped to simulate a failure of some sort, and a restore of the metadata will be performed.

Prior to performing a backup using the md_backup command, we create additional diskgroup objects for demonstration purposes.The following code example will create additional directories, templates, and aliases.This is essential to the backup output that we’ll present later.

1* alter diskgroup data
add alias '+DATA/dbatools/datafile/system.dbf'
for '+DATA/dbatools/datafile/system.256.623974863'
SQL> /

Diskgroup altered.

SQL> alter diskgroup data add directory '+DATA/oradata';

Diskgroup altered.

SQL> alter diskgroup data add directory '+DATA/oradata/DBATOOLS';

Diskgroup altered.
SQL> alter diskgroup data add template temp2 attributes (fine unprotected);

Diskgroup altered.

SQL> alter diskgroup data add template data2 attributes (fine mirror);

Diskgroup altered.

SQL> alter diskgroup data add directory '+DATA/oradata/WWJD';

Diskgroup altered.

SQL> alter diskgroup data
add alias '+DATA/oradata/DBATOOLS/sysaux.dbf'
for '+DATA/dbatools/datafile/sysaux.257.623974863';

Diskgroup altered.

SQL> alter diskgroup data
add alias '+DATA/dbatools/datafile/users.dbf'
for '+DATA/dbatools/datafile/users.259.623974865';

Diskgroup altered.

1* alter diskgroup data
add alias '+DATA/dbatools/tempfile/temp.dbf'
for '+DATA/dbatools/tempfile/temp.264.623975155'
SQL> /

Diskgroup altered.

SQL> alter diskgroup data
add alias '+DATA/dbatools/datafile/undotbs1.dbf'
for '+DATA/dbatools/datafile/undotbs1.258.623974865';

Diskgroup altered.

The previous code example created the ASM templates TEMP2 and DATA2.To prove that the ASM templates are valid and exist within the ASM instance, you can query the V$ASM_TEMPLATE view, as shown here:

SELECT name, redundancy,stripe
from v$asm_template
where system='N'
SQL> /
NAME REDUND STRIPE
---------------------- -------------- -----------
TEMP2 UNPROT FINE
DATA2 MIRROR FINE

Similarly, all the directories created using the alter diskgroup can be confirmed too:

select name,file_number,alias_directory
from v$asm_alias
where system_created='N'
and alias_directory='Y'
SQL> /
NAME FILE_NUMBER A
------------------------ -------------------- ---
oradata 4294967295 Y
DBATOOLS 4294967295 Y
WWJD 4294967295 Y

The diskgroup backup can be invoked using the md_backup command similar to what is displayed here:

ASMCMD> md_backup -o asm_backup.mdb -g data,fra

###User defined intermediate backup file is

/tmp/asm_backup.mdb Disk group to be backed up: DATA# Disk group to be backed up: FRA#
Current alias directory path: oradata/WWJD
Current alias directory path: oradata
Current alias directory path: oradata/DBATOOLS

The asm_backup.mdb file contents are shown next.You can clearly see that this file is a text file.The majority of the data from the TEMPLATEINFO section was deleted to make this output presentable.This section of the file contains the bulk of the information since there were 15 predefined system TEMPLATEINFO items to each diskgroup.You will notice the two custom templates that were created,DATA2 and TEMP2, in the MDB backup file.

+ASM1 > cat /tmp/asm_backup.mdb
@diskgroup_set = (
{
'DISKSINFO' => {
'VOL1' => {
'VOL1' => {
'TOTAL_MB' => '1961',
'FAILGROUP' => 'VOL1',
'NAME' => 'VOL1',
'DGNAME' => 'DATA',
'PATH' => 'ORCL:VOL1'
}
},
..
..
},
'DGINFO' => {
'DGTORESTORE' => 0,
'DGCOMPAT' => '11.1.0.0.0',
'DGNAME' => 'DATA',
'DGDBCOMPAT' => '11.1.0.0.0',
'DGTYPE' => 'NORMAL',
'DGAUSZ' => '1048576'
},
'ALIASINFO' => {
'1' => {
'DGNAME' => 'DATA',
'LEVEL' => 1,
'ALIASNAME' => 'oradata/WWJD',
'REFERENCE_INDEX' => '16777799'
},
'0' => {
'DGNAME' => 'DATA',
'LEVEL' => 0,
'ALIASNAME' => 'oradata',
'REFERENCE_INDEX' => '16777693'
},
'2' => {
'DGNAME' => 'DATA',
'LEVEL' => 1,
'ALIASNAME' => 'oradata/DBATOOLS',
'REFERENCE_INDEX' => '16777746'
}
},
'TEMPLATEINFO' => {
..
..
'2' => {
'DGNAME' => 'DATA',
'STRIPE' => 'FINE',
'TEMPNAME' => 'DATA2',
'REDUNDANCY' => 'MIRROR',
'SYSTEM' => 'N'
},
….
….
'3' => {
'DGNAME' => 'DATA',
'STRIPE' => 'FINE',
'TEMPNAME' => 'TEMP2',
'REDUNDANCY' => 'UNPROT',
'SYSTEM' => 'N'
},
...
...
}
},
{
'DISKSINFO' => {
'VOL3' => {
'VOL3' => {
'TOTAL_MB' => '1952',
'FAILGROUP' => 'VOL3',
'NAME' => 'VOL3',
'DGNAME' => 'FRA',
'PATH' => 'ORCL:VOL3'
}
},
..
..
'DGINFO' => {
'DGTORESTORE' => 0,
'DGCOMPAT' => '11.1.0.0.0',
'DGNAME' => 'FRA',
'DGDBCOMPAT' => '10.1.0.0.0',
'DGTYPE' => 'NORMAL',
'DGAUSZ' => '16777216'
},
'ALIASINFO' => {},
'TEMPLATEINFO' => {
….
….,
'11' => {
'DGNAME' => 'FRA',
'STRIPE' => 'FINE',
'TEMPNAME' => 'CONTROLFILE',
'REDUNDANCY' => 'HIGH',
'SYSTEM' => 'Y'
},
...
...
}
}
);

Since the metadata backup is complete,you are ready to simulate a complete diskgroup failure. The following dismount and drop diskgroup commands will completely expunge everything in the DATA diskgroup:

SQL> alter diskgroup data dismount;Metadata Backup and Restore Demonstration SQL> drop diskgroup data force including contents;

Now it’s time to perform the restore from the previous md_backup command:

ASMCMD> md_restore -t full -g DATA -b /tmp/asm_backup.mdb

Disk group to be restored: DATA#

ASMCMDAMBR-09358, Option -t newdg specified without any override options.
Current Diskgroup being restored: DATA
Diskgroup DATA created!
Template DATA2 created/altered!
Template TEMP2 created/altered!
User Alias directory +DATA/oradata
created!
User Alias directory +DATA/oradata/WWJD
created!
User Alias directory +DATA/oradata/DBATOOLSMetadata Backup and Restore Demonstration

created!At this point,if you examine the alert log of the ASM instance, you will see the SQL statements that were executed behind the scenes.Here’s an excerpt from the alert log file located in the new diag directory, /apps/oracle/diag /rdbms/dbatools/DBATOOLS /trace/alert_ +ASM1.log:

SUCCESS: diskgroup DATA was mounted
SQL> alter diskgroup DATA alter template AUTOBACKUP attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template DATAGUARDCONFIG attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template CONTROLFILE attributes (HIGH FINE)
SQL> alter diskgroup DATA add template DATA2 attributes (MIRROR FINE)
SQL> alter diskgroup DATA alter template DUMPSET attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template PARAMETERFILE attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template ARCHIVELOG attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template TEMPFILE attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template ASM_STALE attributes (HIGH COARSE)
SQL> alter diskgroup DATA add template TEMP2 attributes (UNPROTECTED FINE)
SQL> alter diskgroup DATA alter template CHANGETRACKING attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template BACKUPSET attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template DATAFILE attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template ONLINELOG attributes (MIRROR FINE)
SQL> alter diskgroup DATA alter template FLASHBACK attributes (MIRROR FINE)
SQL> alter diskgroup DATA alter template ASMVDRL attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template XTRANSPORT attributes (MIRROR COARSE)
SQL> alter diskgroup DATA alter template ASMVOL attributes (MIRROR COARSE)
SQL> alter diskgroup DATA add directory '+DATA/oradata'
SQL> alter diskgroup DATA add directory '+DATA/oradata/WWJD'
SQL> alter diskgroup DATA add directory '+DATA/oradata/DBATOOLS'

Since the DATA diskgroup is restored, you are ready to perform the RMAN restore of the database!

Additional md_restore Examples

Here we provide some additional examples of the md_restore command.To perform a restore of the DATA diskgroup from the MDB backup file, use this:

md_restore –t full –g DATA –f /tmp/backupfile

If you want the md_restore command to just re-create the metadata for the DATA diskgroup, you can use the following command.The assumption is that the DATA diskgroup already exists.

md_restore –t nodg –g DATA –i /tmp/backupfile

Now let’s look at how to create a different diskgroup name.In this example,the diskgroup name DATA is remapped to DATA2:

md_restore –t newdg -o "DGNAME=DATA:DATA2" –i /tmp/backupfile

The -of option lets you specify override options in a text file.This example will apply the override options as specified in the dg_over.txt file and restore from the backup file:

md_restore –t newdg –of /tmp/dg_override.txt –i /tmp/backupfile

Bad Block Recovery with ASMCMD

Another new feature of the asmcmd utility is the bad block recovery,which runs automatically for normal and high redundancy disks. When bad spots occur on disks,ASM can detect these spots and recover them by restoring the data from its mirror extent from the other failure group(s). When ASM detects an IO error from an attempted read,it will automatically try to repair that block or blocks from the mirrored extents and write out a relocated copy to produce a successful read. This process occurs only for read blocks and happens automatically.

For the remap command to work,the diskgroups must be in a mounted state.The purpose of the remap command is to read mirrored extents to produce good IO for the primary extent.This is supposed to happen automatically, but you can use the asmcmd repair interface if there are reports of disk errors on the physical block.At this point,you can use the remap command to initiate a read on that block to trigger the repair.The syntax for the remap command is as follows:

remap <diskgroup name> <disk name> <block range>

You can use the remap command for a range of physical—not virtual—blocks on a disk.<diskgroup name> is the name of the diskgroup in which a disk needs to be repaired. <disk name>is the V$ASM_DISK.NAME of the disk that needs to be repaired.<block range> is a rang of physical blocks to repair,in this format:from-to.Here are a couple of examples of this utility. The first command repairs blocks 25 to 100 for the VOL1 disk in the DATA diskgroup. The latter command repairs blocks 5230 to 5300 of the VOL4 disk in the FRA diskgroup.

ASMCMD> remap DATA VOL1 25-100
ASMCMD> remap FRA VOL4 5230-5300

ASM can repair only one extent at a time.If multiple block extents need to be repaired, asmcmd must make multiple passes to repair them one at a time.The remap command assumes that the physical block size is 512 bytes and the allocation unit size is 1MB.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Oracle 11g Topics