{"id":10997,"date":"2018-02-27T15:59:16","date_gmt":"2018-02-27T14:59:16","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/oda-migration-challenges\/"},"modified":"2018-02-27T15:59:16","modified_gmt":"2018-02-27T14:59:16","slug":"oda-migration-challenges","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/oda-migration-challenges\/","title":{"rendered":"ODA migration challenges: Non-OMF to OMF + 11.2.0.3 to 11.2.0.4"},"content":{"rendered":"

To do some application and performances tests, I had to copy a database from a third party Linux server to an ODA X7-2M. Looks pretty simple on the paper, but 2 small challenges came into the game. The first was that of course the source database was in Non-OMF while ODA works fully in OMF. The second was that the source database is running 11.2.0.3 which is not supported and cannot be installed on the ODA “lite”. Therefore I had to find a way to copy the database on 11.2.0.4 binaries and get the upgrade done before opening it.<\/p>\n

<\/p>\n

My first idea was of course to do a duplicate of the source database to the ODA.\u00a0 To get everything ready on ODA side (folders, instance…), I simply created an 11.2.0.4 database using ODACLI CREATE-DATABASE<\/em> and then shut it down to delete all data files, redo logs and control files.<\/p>\n

As duplicate from active database wasn’t possible, I checked the backup of the source database and looked for the best SCN to get to. Once I had defined this I could start preparing my duplicate as following:<\/p>\n

RMAN> run {\n2> set until scn XXXXXXXXX;\n3> allocate channel t1 type disk;\n4> allocate channel t2 type disk;\n5> allocate channel t3 type disk;\n6> allocate channel t4 type disk;\n7> allocate auxiliary channel a1 type disk;\n8> allocate auxiliary channel a2 type disk;\n9> allocate auxiliary channel a3 type disk;\n10> allocate auxiliary channel a4 type disk;\n11> duplicate target database to 'DBTST1';\n12> }<\/pre>\n
As explained above the first little challenge here was that my target database is in Non-OMF and I wanted to make it “proper” on ODA which means OMF based structure.<\/p>\n
Usually in a duplicate you would use db_file_name_convert<\/em> and log_file_name_convert<\/em> to change the path of the files. The issue with this solution is that it will not rename files except if you do it file per file.<\/p>\n
The second option is to use in RMAN the command SET NEWNAME FOR DATAFILE<\/em>. Here same “issue” I have to do it file per file and I had more than 180 files. Of course I could easily script it with SQLPlus but the list would be awful and not easy to crosscheck\u00a0 if I’m missing anything. In addition doing the SETNAME<\/em> requires to take some precaution as the file name still need to be OMF generated. This can be handled by providing followings string for the filename: 01_mf_<dbname>_%u.dbf<\/p>\n
However I still wanted a more “elegant” way. The solution indeed was simply to use SET NEWNAME FOR DATABASE<\/em> in conjunction with the TO NEW<\/em> option. This automatically generates a new file name for all database files. The condition there is that following parameters are properly set on the auxiliary database:<\/p>\n