If you migrate an Oracle Database using cross-platform transportable tablespaces (XTTS) and incremental backups and if your target database use ASM, you should get rid of the aliases after the migration.
What Is an ASM Alias?
When you use ASM, there is tight control over the file names. ASM strictly enforces the naming standard dictated by Oracle Managed Files (OMF), and only the database can create file names that comply with OMF.
Sometimes it is handy to create files in other locations in ASM that still refer to a database file. Here you can use aliases. Aliases work like a symbolic link in the file system.
How can you tell if a file is an alias?
Alias Oracle ASM file names are distinguished from fully qualified file names or numeric file names because they do not end in a dotted pair of numbers. It is an error to attempt to create an alias that ends in a dotted pair of numbers, such as in the format USERS.259.685366091.
When you use
ls -l you can also tell whether a file is an alias. The column SYS (System-generated) is N, meaning this is not a proper OMF file. Also, you can see in the Name column that it is an alias. The
=> indicate it:
ASMCMD> ls -l +DATA Type Redund Striped Time Sys Name DATAFILE UNPROT COARSE MAR 16 08:00:00 N account_25.dbf => +DATA/CDB1_FRA2KR/86D5DC2587337002E0532AB2A8C0A57C/DATAFILE/ACCOUNT.282.1099469855 DATAFILE UNPROT COARSE MAR 16 08:00:00 N accountidx_26.dbf => +DATA/CDB1_FRA2KR/86D5DC2587337002E0532AB2A8C0A57C/DATAFILE/ACCOUNTIDX.280.1099469855
You can read about Fully Qualified File Name Form in the ASM documentation, if you are interested.
Why Are the Aliases Created?
When the Perl script is restoring and recovering the data files on the target database, they do not belong to any database yet. The tablespaces have not been plugged into any database yet. Hence, it is impossible to figure out the right OMF name of the data files.
As an alternative, ASM names the data files according to the syntax of the source database. For instance, it will use the source database GUID (
select guid from v$containers) as part of the name.
In addition, the Perl script creates ASM aliases using the following format:
When you perform the Data Pump import, you can refer to the aliases in your Data Pump parameter file (
transport_datafile). Using the aliases is especially useful if you plan on having a standby database.
How Do I Get Rid of the Aliases?
After performing the Data Pump import, the tablespaces are plugged into a database, and now the data files belong to a database. But the target database is referring to the data files either via:
- An ASM alias
- Or directly via the absolute file name. As described earlier, the absolute file path uses the OMF syntax of the source database
Let me illustrate that. Imagine:
- In xtt.properties
- My data file is named users01.dbf, belongs to tablespace USERS and has file ID 65.
- Source database GUID is 86D5DC2587337002E0532AB2A8C0A57C.
How will the file be registered in the database?
- If I used the aliases, it is known as +DATA/users_65.dbf.
- If I used the absolute file name, it is known as +DATA/SALES2/86D5DC2587337002E0532AB2A8C0A57C/DATAFILE/users.280.1099469855. ASM generates the last two sets of numbers.
Neither of the two formats is proper OMF names. What is the real OMF name? Imagine:
- Target database GUID is DA495482D68D0220E0530F01000A98DF
- The real OMF file name is (notice the change in GUID): +DATA/SALES2/DA495482D68D0220E0530F01000A98DF/DATAFILE/users.280.1099469855
You can get the GUID of a database by using
select guid from v$containers.
In ASM, only the database can store a file in OMF syntax. You must fix this from the target database. The easiest way is to use online data file move. If you don’t specify the target location, the database will generate an OMF name:
SQL> --using file number SQL> alter database move datafile 65; SQL> --using full name SQL> alter database move datafile '+DATA/users_65.dbf';
How does the move work?
- It is a entirely online operation.
- It is a block-by-block copy.
- The database copies the data file. While the copy operation takes place, the two files are kept in sync until the database can switch to the new file. After that, the database removes the original file.
- If the data file belongs to a PDB, you must switch your session to that container.
You can learn more about online data file move in our YouTube video:
If my database works fine, why should I worry? I can think of at least two reasons:
- Comply to naming standard
- Avoid problems in other migrations
Comply to naming standard
I highly recommend that you use and comply with any naming standard, including OMF. Data files that are not appropriately stored according to OMF, should be moved to the correct location.
When I worked outside in the real world as a DBA, I remember multiple occasions of loss of data files. In many situations, a DBA had found a file apparently not belonging to a database – at least according to the naming standard. But the file was used by a database; it was just not stored in the correct location. When the file was removed = big problem in the database.
With many databases and many hosts, it is very important that you make standards and keep with the standards. Otherwise, you will end up in a big mess.
Avoid problems in other migrations
This is especially relevant if you need to perform multiple migrations to the same database host.
The Perl script used for the migration will create the aliases in the location specified by
dest_datafile_location. The names of the aliases are very simple, and there is a risk that another migration will try to make the same alias.
Imagine you already did one migration. The database uses the alias +DATA/users_4.dbf. Now you want to make a second migration, and this database also wants to use +DATA/users_4.dbf. The same alias can’t be used for two different files. Big problem!
A user left a comment on my blog telling me this actually lead to corruption in the first database. That risk is a very good reason for getting rid of the aliases and using only proper OMF file names.
ASM aliases are created automatically as part of the migration. The aliases are very useful during the migration, but I highly recommend getting rid of the aliases right after the migration.
Other Blog Posts in This Series
- Full Transportable Export/Import
- What Is a Self-contained Transportable Tablespace Set
- How to Migrate a Database Using Full Transportable Export/Import and Incremental Backups
- Make It Fast
- Backup on Standby Database
- Slow Network Between Source and Target
- Bigfile Tablespaces
- Testing the Procedure On Activated Standby Database
- Testing the Procedure Multiple Times Using Read-Only Tablespaces
- Target Database and Data Guard
- ASM Aliases and Why You Should Get Rid of Them
- Pro Tips
3 thoughts on “XTTS: ASM Aliases and Why You Should Get Rid of Them”
I have simply took care of asm aliases during impdp ( metadata import process). So trick was not to use asm_alias in transport_datafiles clause but use absolute path. You can easily get path using asmcmd -p and do ls -l and copy or store output in some text file and use awk command to get list of all datafiles which is after => character and to use in impdp
userid=’/ as sysdba’
After impdp is done, you can simply remove alias by using rmalias command in asmcmd ( not rm ) since all datafiles should be using full path. You can confirm by querying v$datafile.
LikeLiked by 1 person
Thanks for the input. You can do that, except it wont work if you want to prepare the data files for a standby database as well. Then you must use the aliases.
In addition, the absolute file names are syntactically an OMF name, but it doesn’t match the convention of the target database. The GUID part of the file name will be wrong – check select guid from v$containers.
LikeLiked by 1 person
Thanks Daniel, I am not using container so that’s why I did not experience this issue. You are correct if you want to build your primary & standby at the same time using XTTS then you have to use asm aliases and deal with asm alias later on. However building standby using XTTS at the same time you are building primary is not discussed in any of Oracle support notes. I did test out process though by myself and it involves some extra steps e.g. using different folder location on standby , copy res.txt to standby etc.
LikeLiked by 1 person