2 Replies Latest reply: May 3, 2013 10:33 AM by EarlB RSS

    Migrate Teradata To Oracle -- Permissions

      I am performing a migration of an existing Teradata database to Oracle using the migration feature included in Oracle SQL Developer. I have successfully configured my JDBC connectors and can access the Teradata database, but the Teradata DBA is not sure what permissions I need (on Teradata) to reverse engineer the Teradata database. Is there a list of the Teradata permissions I will require to accomplish the reverse engineering?

      Thanks in advance.
        • 1. Re: Migrate Teradata To Oracle -- Permissions
          The manual states:

          To configure a Teradata database for migration:

          Ensure that the source database is accessible by the Teradata database user that is used by SQL Developer for the source connection. This user must be able to see any objects to be captured in the Teradata database; objects that the user cannot see are not captured.

          So best would be to be a DBA privileged user as you need access to the dictionary and to all objects you want to migrate. If your Teradata admin does not want to grant you DBA privs, you can also perform an OFFLINE migration. Click on Tools -> Migration -> database capture scripts. Make sure to select the correct Teradata release and the operating system where the Teradata database is running. Now click on create scripts and pass the scripts for the offline migration model creation to your Teradata dba so that he can run them.
          It will create subdirs and it would be best if your admin could zip them and pass them to you so that you can then perfomr an offline data model migration.

          - Klaus
          • 2. Re: Migrate Teradata To Oracle -- Permissions
            Thanks, I was aware of that. I was actually hoping to find out if there was any sort of Teradata privilege that would be equivalent to the Oracle "SELECT ANY DICTIONARY" and "SELECT ANY TABLE" priivileges, which would be sufficient to do the job in Teradata, as the DBA has little time to support the reverse engineering effort.