Export table content using a transport of copies #sapadmin
Exporting table content using a transport of copies is sometimes used to export table data out of a SAP system before the database is refreshed. Once the database is refreshed the transport request is imported again to insert the entries back into the table. There are other means of exporting table data of course but some tables cannot be exported using the EXP or BR*Tools from Oracle for example so this can come in handy.
*EDIT Note that using Oracle EXP seperately is not supported by SAP so I don’t recommend you start using EXP.
Picture 1.0
Go to transaction SE01
Click on Request à \ Create
Picture 1.1
Select Transport of copies
Click yes
Picture 1.2
Provide a short description for your transport request
Enter the SID of your SAP system in the Target field
Click save
Picture 1.3
Now double-click the Request <SID>K90043 (for example) \ under the header Modifiable
Picture 1.4
Click on the Pencil icon to go into change mode
Picture 1.5
Now insert R3TR TABU into Pro Obj columns
Insert the name of the table you wish to export in the \ Object Name column
Picture 1.6
Now click on the key Icon next to the Object Name column
Picture 1.7
If you want to export the full table content insert a * into \ the Table Keys field
Save
Picture 1.8
If you now go back into transaction SE01 you will notice the \ Table Contents appearing under the transport request.
Picture 1.9
Place your cursor on the transport request and push the \ release button to release the transport request. At that moment the table data \ will be exported into the transport request.
Once the transport request is released (and the release \ finished successfully) you should see the data- and cofile of this transport \ request in your transport directory. You can then use the transport request to \ import the table data again at a later points in time (after a database refresh \ for example).
great post, as usual.
Question:
is there a limit for this ?
I mean, can you also use this with BIG-record tables as well ?
Regards
Thanks for your comment.
Exporting table content as described in the blog uses R3trans -w to place the content in a transport request.
Note 1942 - How does R3trans work?
Extract from SAP Note 1942:
"R3trans can also be used for data migration (export from the old system with the old R3trans and import into the new system with the new R3trans)."
So yes you can also export seriously big tables using this method.
Typical tables that are exported before the refresh of a database and imported afterwards again are not large at all.
Kind regards
Tom
as usual, quite a real-life focussed blog post.
Thanks for keeping this up!
One comment though:
Data export/import via Oracle EXP/IMP (or EXPDB/IMPDP) is supported _only_ when used with the BRTOOLS for reorganisation purposes.
There are several things that can be done wrong here easily, leading to crippled data (NLS conversion!) so this really shouldn't be considered an option for moving data between two systems.
Nevertheless, what kind of data did you had in mind when you wrote, that EXP cannot export all types of data? Technically, all data storing oracle objects can be exported.
regards,
Lars
Thanks for your comment.
RFCDOC table for example which is a pool table.
We have Oracle EXP in place to export data from system AA1 (for example) before Oracle DB refresh and then inserting the data back in AA1 after Oracle DB refresh is finished. We haven't experienced issues with it yet.
Kind regards
Tom
Of course you cannot access pool/cluster tables directly, but only the base tables for those.
Concerning your experience: sure, the EXP/IMP can work and can lead to the correct results.
That's true for many features and still, it's just not supported.
So, when somebody reads this post, tries it out and something goes wrong - we (SAP) won't support this.
For your scenario I would consider the usage of
transportable tablespaces anyhow - much faster, much safer.
Or - if you do this just to protect your application data during the upgrade - simply offline the tablespaces with the application data during the upgrade 😉
cheers,
Lars
Yeah I know 🙂
It's not my intention to pursuade people not to follow SAP supported way. The EXP was already in place before I joined in.
I'll place an edit in the blog post to mention it.
Thanks for the tips.
Kind regards
Tom
Thanks for contributing to the added value of the blog.
Does that make sense that it would delete records or should it be considered as a bug?
Kind regards
Tom
If misued, however, it can lead to confusion, especially as there is no "whoops" button in STMS to undo an inappropriate transport...
I know SAP has got some "hidden" codes and tricks to operate R3trans as well to get systems back on track in really sticky situations. I would love to get my hands on those 😉
I agree with the fact that these types of actions should be practiced carefully but then again that's always the case for administration actions.
If you don't know what you're doing you can mess up your SAP system. There could and perhaps should be warnings triggered when performing some of the more dangerous administration actions.
Exporting the wrong tables or not enough tables (not taking into account table relationships) can also cause inconsistencies and basically aid in messing up your SAP system.
I plan to create some more tips / tricks blogs for #sapadmin's. I'm aware that some actions are tricky / dangerous or even expose security risks (if security is not tight enough) and I'll do my best to highlight that in the blogs but in the end I do feel like these kind of actions should be known by #sapadmin's to resolve certain issue or problem situations.
Kind regards
Tom
Regards,
Abnash
Thanks for your comment.
The link you provide is indeed a good contribution to this blog as it provides related information on selecting a range of records instead of a full table.
There is a fundamental difference though between the blogs. The link that you provide shows a workbench request creation in a development system (presumably a development).
My blog shows a transport of copies creation which can be used to export table content in a QAS system with as target my QAS SID (for a refresh scenario for example). I would not be able to perform these actions by creating a workbench request in my QAS system due to the way TMS is configured.
Kind regards
Tom
Regards,
Abinash
We've been using this technique for years when applying HR Support Packages.
If you don't export the content of tables T512W and T512T before applying the HR SP and reimport them after applying the HR SP, you break the payroll !
Thanks for nice info addition on HR 🙂
This blog is gaining more value each comment, love it!
Kind regards
Tom
I was wondering if you have experience with report RPU12W0S for the HR wages backup/copy as alternative method to using a transport request.
Kind regards
Tom
Yes we know RPU12W0S but our payroll consultant tells us that the result is not good enough for him.
We even now export and reimport tables T511K and T511P together with T512W and T512T.
Olivier
Thanks for your reply, interesting information 🙂
Kind regards
Tom
I wonder if your consultant knows that exporting and importing the tables after SP update will introduce a risk of deleting your data because there’s a chance it changes some fields during that process.
There should be documentation to support your goal from SAP, but the export import method is not one of that.
I would suggest trying it in a sandbox environment first and testing everything works beforehand if you really need to do that.
great post, thank you.
One additional question. Do I have to create a transport request in every client or is it possible to export table entries client independent in one transport request.
Regards
Andreas
Thx for your comment.
Using * as mentioned in this blog post will export all entries meaning the data of that particular table for all clients.
You can of course also export the data of multiple tables in a single transport request. You can set the key value per table so you can export table A for all clients and table B for a single client as well for example.
You can take a look at the other blog that is linked in the comments to see how you can select data from a single client.
Kind regards
Tom
As usual Heartiest Thanks for the blog which gets used in our work.
Tom, I am trying hard to understand the difference b/w Workbench and transport of copies.But am not able to conclude well with the comments below.
I remember,in a similar situation to copy entries of a table I created a Workbench request as we generally deal only with workbench and customizing entries. Can you please tell me?
Regards,
Kumud
The choice depends on how your transport routes are set up. I could use workbench request if I was exporting the table content from the development SAP systems because there I can choose a consolidation route
In the example shown in this blog though the table content is exported from acceptance and there is no consolidation route from acceptance to production hence I cannot provide a proper target for a workbench request.
A transport of copies can have the SAP system itself as target instead of a transport route and that's why this is used here.
Hopefully that makes for a better explanation but if you want some visuals on that I'll mail it to you if you want to be able to give a better explanation. Visuals work better than words sometimes.
Kind regards
Tom
Thanks much.
Regards,
Kumud
It's not impossible to create a workbench request without a consolidation route but it is considered dangerous at least as you can cause inconsistencies.
A transport of copies does not get added to the import queue of SAP systems down the transport route automatically.
I'll send you a word doc with some explanation.
Kind regards
Tom
Mail has been sent.
Everything depends on how STMS is configured.
Kind regards
Tom