Expert Oracle Exadata - Parent Directory

CHAPTER 13 MIGRATING TO EXADATA2. Install the RAC system objects by running the catclust.sql script as the sysuser.3. Register the new database with Cluster Ready Services (CRS):a. Register the database.b. Register the instances.c. Create Service Names for the database.4. Create an additional redo thread for each instance. Note that thread 1 isalready active for the first instance.5. Create an Undo tablespace for each database instance. Note that one alreadyexists for the first instance.Wrap Up Physical Migration SectionPhysical migration may prove to be an easy migration option if your application schema is complexenough that you don’t want to take any logical path. Also, physical migration can potentially be donewith very low downtime, by restoring a production copy to the Exadata database as a physical standbydatabase and applying production archivelogs until it’s time to switch over and make standby the newproduction database. However this approach cannot be used between platforms with differentendianness and there are a few more Oracle version specific restrictions.Dealing with Old init.ora ParametersWhen migrating from an older version of Oracle, you might be tempted to keep all the old(undocumented) init.ora parameters for “tuning” or “stability”. The fact is that Oracle has very gooddefault values for its parameters since 10g, especially so in 11.2; which likely runs on your Exadatacluster. Whatever problems were solved by setting these undocumented parameters years ago, areprobably fixed in the database code already. Also, moving to Exadata brings a much bigger change thanany parameter adjustment can introduce, so the stability point is also moot. As such, it’s recommendednot to carry over any undocumented parameters from the old databases, unless your application (likeOracle Siebel, SAP) documentation clearly states it as a requirement.Also, there are some documented parameters which should be unset when migrating to Oracle 11.2,to allow Oracle to pick appropriate values automatically:db_file_multiblock_read_count: This parameter should be unset, as starting fromOracle 10.2 the database can pick the appropriate values for it automatically. Infact, this way there actually two different multiblock read count parameters usedin Oracle, one for costing and one for execution. This arrangement generallyworks better than leaving the parameter set to some arbitrary value which affectsboth the costing and the execution.• parallel_execution_message_size: if you have tuned this parameter in past (toreduce PX Qref latch contention or parallel messaging overhead) then you canunset it, as the default value for this parameter is 16kB starting from Oracle 11.2464