Re: Transportable Tablespace Problem - Missing Views

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: david.barbour1@xxxxxxxxx, oracle-l mailing list <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 9 Oct 2014 21:16:57 +0200 (CEST)

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:

>> 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

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.

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

> David Barbour <david.barbour1@xxxxxxxxx> 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 
> 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?

Other related posts: