CPAT Frequently Asked Questions

Hi,

The CPAT Development team created a great F.A.Q. and I’d like to share it with CPAT users.

What are the various approaches to running CPAT?

  • Download and run CPAT directly (from MOS)
  • Download and run SQLcl and use SQLcl to run CPAT.  Using SQLcl is likely the best option if
    • You don’t have access to MOS, or,
    • You’re struggling with JDBC connect strings, Java JRE versions, etc.  Let SQLcl figure it out.
      • Make sure you check the CPAT version (MIGRATEADVISOR VERSION command) used by SQLcl (23.3.1 is a very old version).
  • Use ZDM which will run CPAT for you and handle fetching properties from the target instance 
  • Use DMS which uses ZDM (same as above)
  • Use EM Migration Workbench

Does running CPAT require altering your database?  Does CPAT write to your database?

  • No! CPAT Treats Your Database As READ ONLY!
  • No new users! No new roles! No new packages! No temporary tables! No writes at all!!

What privileges does CPAT require?

  • As mentioned below, most of the queries executed by CPAT are against the data dictionary therefore CPAT requires the SELECT ANY DICTIONARY privilege
  • You may also want to connect as a schema that has been granted SELECT on SYSTEM.DUM$COLUMNS and SYSTEM.DUM$DATABASE.
    • Access to the DUM$ tables is needed only if the source and target character sets indicate that Oracle Database Migration Assistant for Unicode (DMU) is required.

Does CPAT connect to the internet?

  • CPAT does not “phone home”!
  • CPAT does not connect to the internet unless you use the command line option that instructs CPAT to check to see if an updated version of the app is available.

How does the checks run by CPAT compare to Oracle Estate Explorer?

  • Oracle Estate Explorer runs what amounts to a subset of CPAT queries. As such its reports can be less than complete and may result in an overly simplistic view of what’s needed to achieve a successful migration.
  • Using other tools (e.g. CMA) can get similar estate depictions using CPAT results (again, those results would never leave your network/systems).

What versions of Java is required to run CPAT?

  • A Java 7 (or higher) JVM is required to run CPAT
  • All Oracle releases from 11g on up either come with a supported Java version or can be patched to have a supported version
  • You do not have to use the JRE in the ORACLE_HOME of the instance you wish to analyze with CPAT.
  • You can run CPAT from any JVM (Java 7 or higher) either on the same host as the instance you want to analyze or from anywhere else on the network that has (SQLnet/JDBC) connectivity to the instance you want to analyze.
  • That said, for best results, Oracle recommends using a 64-bit JVM, version 8 or higher.

How does CPAT connect to the source (or target) database?  What authentication methods are supported?

  • CPAT connects to your database using JDBC.
  • Oracle JDBC connect strings are URL-based and always begin with jdbc:oracle:thin:@ or jdbc:oracle:oci:@
  • Example CPAT connect strings are given in the CPAT MOS Note and Database Documentation
  • You can use whatever JDBC connection string works best for your situation (connectivity/security). Thin or Thick (OCI).
  • Use whatever authentication/security you’d like:
    • simple username/password
    • wallets
    • Kerberos
    • anything supported by OJDBC
  • If you want to use OS Authentication then you need to use the thick driver and have an ORACLE_HOME with the required binaries.
  • ZDM typically uses OS Authentication
  • Anecdotally most people connect as SYSTEM

What Database Versions are Supported by CPAT?

  • CPAT was designed to work with 11g and up (Enterprise Editions)
  • CPAT should work with 10g (we know of no issues currently)
  • CPAT will attempt to work on unsupported versions on a “best effort” basis.

Does CPAT share information with Oracle?

  • No!
  • Once the CPAT report(s) are written the CPAT is done.  Customers are free to do whatever they want with those reports.
  • Customers need not share their reports with anyone (or Oracle in particular) so those reports never need to leave your systems/network.

What information does CPAT gather/what queries does CPAT do? 

  • CPAT runs a bunch of queries (mostly against data dictionary tables) to generate reports.
  • Once CPAT completes generating the reports requested (TEXT, HTML, JSON) and exits everything is garbage collected and goes into the proverbial bit bucket.  What’s ultimately done with those reports is up to the customer.  If they’re using DMS or ZDM the JSON report will be used to aid in guiding the customer through a successful migration.
  • CPAT fetches information related to:
    • Database identification, version/patch info, etc.
      • Information useful for relating the report to a specific database and the general state of that database
    • CPAT does preparatory queries that affect which Checks /should/ CPAT do (e.g. is XDB installed?  No, then skip the XDB checks)
  • CPAT looks for other helpful info
    • If the ORACLE_MAINTAINED column is there we can use that.
    • What are the TABLESPACE names we need to worry about?  Can we ignore some?
  • The queries for the Checks themselves.
    • These are mostly queries against the data dictionary to find anything being used in the source instance that either
      • Isn’t supported by ADB
      • Isn’t supported by the Migration Methods chosen (DataPump and OGG)
    • These queries are generally of the nature of “Is this datatype in use”, “Is that feature in use”, etc.
  • The queries ultimately used for Checks are included in the generated reports (HTML, JSON always, TEXT if you use –sqltext)