I would like to get the exhaustive list of tables we have to export with R3trans before a system refresh.
Do anyone get this kind of information ?
I am experienced in systems refresh on Oracle database, but I have to manually execute all the usual tasks in SAP, on the target system after the database refresh.
I am used to export RFCDES, RFCATTRIB, RFCDOC, but I have never found a complete list of all the other tables we could export before refresh.
It seems that it's possible to export the tables for STMS settings, RZ10, RFC, BDLS, and so on.
Please, if someone could help, it would be helpfull !
Many thanks to all of you.
In addition to what you have identified, you may export the following tables
TSP03 - Printers
E070L - Transport request
USR, AGR -> export usermasters and profiles
RFCDES - RFC destinations
V_TBDLS - Partner profiles
BDLS you can run post refresh. Hence no need to download that data.
Go through this link
Apart from this , if you have JAVA there are some configuration table for JAva also
Hope this helps you. find below tables you need to preserve using R3trans prior to refresh.
RFC (For retaining RFC connections) : RFCATTRIB, RFCDES, RFCDOC
AL11 (For retaining AL11 entries : USER_DIR
DB Static history (For retaining database statistics history ) : DBCHECKORA
TMS (For retaining TMS approvals history) : TMSQWL,TMSQNOTES,TMSQWLF
Venkata S Pagolu
Venkata Pagolu wrote:
> Hope this helps you. find below tables you need to preserve using R3trans prior to refresh.
> RFC (For retaining RFC connections) : RFCATTRIB, RFCDES, RFCDOC
> AL11 (For retaining AL11 entries : USER_DIR
> DB Static history (For retaining database statistics history ) : DBCHECKORA
> TMS (For retaining TMS approvals history) : TMSQWL,TMSQNOTES,TMSQWLF
> Venkata S Pagolu
DBCHECKORA does not contain stats it hold the condition paterns BR*tools are using to perform the check DB action.
Statistics could be exported using BR*tool or package DMBS_STATS.EXPORT_TABLE_STATS
Because I think it would be precious for lot of us, I propose to put all the necesary tables to keep in this post.
If some of you know important tables to keep, before a system refresh, to be able to automate some post refresh tasks with R3trans tool, please copy/paste the following list and add your entries.
Hope this helps ; thanks for your interest.
At this moment, after reading lot of forums, made some tries, I think the following tables are to keep :
- Users (profiles and so on) : ADR, AGR, SMEN, SSM, USG, USR, UST* (client dependant).
- RFC : RFC, RSEC (client independant)
- BDLS : TBDLS, TBDLST, V_TBDLS (client independant ?)
- Transports : E070L, TMSQWL, TMSQNOTES, TMSQWLF (client independant ?)
- License : SAPLIKEY (client independant)
Here are some other tables you could find useful to export before copy / refresh
For Archive link
TOAOM SAP ArchiveLink: Meta table for links
For RFC dest it might be useful to export
RFCDOC Description of Possible RFC Connections (->RFCDES)
RFCDES Destination table for Remote Function Call
If you are using ALE :
EDIPOA Table for ALE Port Definitions (used only for ALE)
EDIPOD File port definition
EDP13 outbound parameters
EDP21 inbound parameters
EDIPORT Summary table
EDPP1 EDI Partner (general partner profiles - inb. and outb.)
If you are refreshing a CUA master, you need to export ALE conf + the following tables
USZBVSYS CUA: Assignment of Systems to Users
USL04 CUA: Assignment of Users to Local Profiles
USLA04 CUA: Assignment of Users to Roles
For CUA child system
USBAPILINK CUA: Default BAPI Link for Central User Administration
And an unsorted list of tables
TABNAME Client Dep. Text
CREP client indep KPRO CMS: Content Repositories
DBCON client indep Description of Database Connections
EDBAS client indep Basic types
EDIMSG client indep Output Types and Assignment to IDoc Types
EDIMSGT client indep Short description of SAP message types
EDIPOA client dependent Table for ALE Port Definitions
EDIPORT client dependent Summary Table for all Port Types for IDoc Processing
EDP13 client dependent Partner Profile: Outbound (technical parameters)
EDP21 client dependent Partner Profile: Inbound
EDPP1 client dependent EDI Partner (general partner profiles - inb. and outb.)
IACORDES client indep RFC Destinations for IACOR
INSTVERS client indep Documentation for installation Status and History
RFCATTRIB client indep Administration table for RFC destinations
RFCCHECK client indep Table for asynchronous RFC administration
RFCDES client indep Destination table for Remote Function Call
RFCDESSECU client indep SNC extensions for RFC destinations
RFCDOC client indep Description of Possible RFC Connections (->RFCDES)
RFCSYSACL client indep List of permitted trusted systems for the current system
RFCTRUST client indep List of existing trusting systems
RSADMINA client indep Control Table that Customer can Change
RSBASIDOC client indep Assignment of source systems to BIW systems incl. IDoc type
RSECACHK client indep Table for Controlling ABAP Programs
RSECACTB client indep Table for ABAP Access Authorization for Secure Memory
RSECTAB client dependent Secure Memory: Memory for Encrypted Data
RZLLITAB client indep Assignments of Logon/Server Groups to Instances
TOAAR client indep Communications configuration table for storage system
TOAOM client dependent SAP ArchiveLink: Meta table for links
TOASR client indep Language-Dependent Table For TOAAR
TPFET client indep Table of profile parameters
TPFHT client indep Profile header, administration data for profiles in DB
TPFID client indep Description of SAP instance
By the way if you want to know the client dependency of a table you can either
1) check if it contains an MANDT field
2) check if field clidep field is tagged in DD02L
3) check if field CLIENTPOS is set to 0 in DDNTT
Sorry if I'm bumping this post but I thought this info could be very useful to anyone investigating this subject.
running report 'SCTC_LIST_TABLES' using se38 will list all the configuration tables that affect your system. Use R3trans as usual to export / import the tables.
If you are comfortable using SolMan the task list SAP_BASIS_COPY_REFRESH_EXPORT should walk you through the steps...
There are simpler ways to retain data in the target system besides using DBMS tools to extract data before a system copy, then reload it. While the data volumes may be greater (i.e. the extract and reload steps may take longer) because you're storing a bit more than you actually HAVE to, there is actually less for you to do and monitor.
Examples that I have seen / used recently include:
1) License details for your target system can be stored in the source system via SLICENSE,
2) You can store some of your RFC information - those with device or server dependent names - for your target system in your source system, via SM59 - This may or may not be safe, depending on your physical and logical network security (for example, you want to make sure that no one can send a message to a production PI system via a test system),
3) User details (including authorizations and profiles) can be extracted via a Client Copy to a transport, using the appropriate profile (which I can't remember right now !!). This is especially useful when refreshing a test system (where developers may already have stronger access) from a production system.
4) Depending on exactly what data needs to be changed, you can also use technique 3 for customizing data.