Re: Transportable Tablespace Problem - Missing Views

From: Stefan Koehler <contact_at_soocs.de>
Date: Thu, 9 Oct 2014 21:16:57 +0200 (CEST)
Message-ID: <145449957.273976.1412882217276.open-xchange_at_app02.ox.hosteurope.de>



Hi David,
yes, for sure. I have written a blog post about Cross-Platform Transportable Database some time ago, but Cross-Platform Transportable Tablespaces are supported now by SAP as well: http://scn.sap.com/community/oracle/blog/2010/05/09/oracle-migrating-sap-systems-on-oracle-with-less-effort

>> Now do I need to go back and do a metadata export of the souce again and apply to the destination?

Yes (theoretical and from a technical point of view), with a filter on the SAP schemas, but it is usually not that easy in SAP environments as the amount of (manual) post processing steps depends on the kind of SAP system (ABAP or J2EE). The conversion procedure is also supported by BR*Tools nowadays (advantage: automatic post processing is done to some level as well). Please check SAPnote #1003028 for more details about the necessary post steps.

------------------------------8<------------------------------------
3.6. Importing user tablespaces into the new database

On completion of this action and some automatic postprocessing by the system (for example, running the postdbcr.sql script), the new database opens. The copied database is now available in the SAP system for the additional postprocessing described in the system copy guide. …

These steps are described in the guide "System Copy for SAP Systems Based on SAP NetWeaver ...", for example:
* You must create a corresponding OPS$-DB user (containing the tables SAPUSER) for the new <sid>adm OS user.
* To fill the SAPUSER tables, you must reset the DB password for the SAP DB owner (brconnect -f chpass -o sap<sid>).
* ...

You can also use SAPinst for postprocessing. For databases with a Java schema, you should use SAPinst to perform these postprocessing steps because, depending on the release, more extensive postprocessing actions are required for Java systems. The prerequisite for using SAPinst is that you have performed a preparation step in the source system. Refer to the relevant system copy guides for more information. In addition, ensure that the database is stopped before SAPinst is started.
------------------------------8<------------------------------------

I have done that manual post processing steps once for ABAP systems, but in case of ABAP it is pretty well known what kind of additional settings, users or objects are needed.

Best Regards
Stefan Koehler

Oracle performance consultant and researcher http://www.soocs.de

> David Barbour <david.barbour1_at_gmail.com> hat am 9. Oktober 2014 um 20:14 geschrieben:
>
> I've just completed a TTS migration from Oracle 10g on HPUX IA to Oracle 11g on Linux RHEL 6.4.
>
> It's an SAP system and I seem to be missing some of the views.
>
> I know the doc (243304.1) says that "Among other things, objects that reside in the SYSTEM tablespace and objects owned by SYS will not be
> transported. This includes but
> is not limited to users, privileges, PL/SQL stored procedures, and views." but these objects are owned by the SAP user. However Doc 1166564.1
> points out in FAQ#23 that " What if I don't wind up with the same number of non-SYS-owned objects in the target database as in the source? - Use the
> structural export to recreate missing objects for the schemas that were transported. -
> Objects such as users, functions, procedures, views, etc. are not necessarily contained in the tablespaces you transport, since SYSTEM and SYSAUX
> are not transported. You should use a structural import (i.e. full export/import with no rows) after the TTS import to create any missing objects
> that you need."
>
> I did do the dbms_tts.transport_set_check and it worked. And I did the expdp and impdp of the tablespaces. Everything seemed to work. The
> conversion (using RMAN) went smoothly.
>
> Now do I need to go back and do a metadata export of the souce again and apply to the destination? I've already opened the tablespaces to read
> write, which I wouldn't think is a problem since we're talking views, etc. here and not data or structure.
>
> Surely someone has run across this before?
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Oct 09 2014 - 21:16:57 CEST

Original text of this message