Re: Splitting of tables on the basis of partnum
- From: Christian Knappke <chknews@xxxxxxx>
- Date: Thu, 26 Mar 2009 16:13:23 +0100
Salman Qayyum wrote:
Also, I am sure we can partition the larger tables into multiple
smaller tables by updating the partnum on the table systables. If
anybody can guide, that would be really great.
I would not even think about this approach!
A method that might work is: shutdown the SAP system, detach all
fragments of objk into separate tables, unload these in parallel,
unload all the rest, load everything into the target database, insert
data of separate fragment tables into objk. Caution: this is not
supported by SAP and it affords manual intervention and brains work.
Try, test, practice thoroughly, preferably on a test system.
But, as I mentined before, what about archiving?
Our Env:
SAP R/3 4.6B
Kernel : 4.6D_EXT
Database : IDS 10.00.FC7XB
Ask SAP if R3load according to note 952451 can be used with your system.
HTH and best regards
Christian
--
Disclaimer: all recommendations and ideas mentioned above or below are
my own and not necessarily those of my employer. Everything must be
tested before applying it in a production environment.
.
On Mar 26, 3:45 pm, Christian Knappke <chkn...@xxxxxxx> wrote:
Salman Qayyum schrieb:
Hi all,Hi Salman,
We are in the process of migrating of our informix database to oracle
database in SAP environment. We are using SAP specific tools (R3load)
to do the migration.
Here, while exporting the informix database its taking a very long
time. Hence, we are planning to split the large tables into a number
of smaller tables. For Example: There is a table objk which is around
350 GB and it is taking about 20 Hrs to export. Here, if we can split
this table into 8 smaller tables, the export would finish in say 3
Hrs. If anybody can suggest how we can split this table on the basis
of partnum. Something like " update systables set partnum = xxxxx
where tabid =XXX and partnum = xxx it would be really helpful.
(and to all others who have answered so far)
A database migration in an SAP environment is quite a peculiar thing.
Usually the target database is not the same as the source database, so
all database specific tools and methods fail (backup/restore, HPL).
There is a tool by SAP, R3load, that performs an unload (and
afterwards the load) in a totally database independent manner. It is
the only tool that is supported by SAP and it is well integrated into
the installation scripts.
There are certain techniques that help to speed up the migration:
- Archiving, the SAP method to remove old business data from the
database. Do it. Do it thoroughly. (Use transaction SARA, object
PM_ORDER for table objk, among others)
- Get a certified /and/ experienced consultant.
- As for the table objk, R3load can split on table level.
See SAP note 952514.
Find further information onhttp://service.sap.com/osdbmigration.
If you need help, ask SAP on component BC_INS-MIG.
HTH and best regards
Christian
- References:
- Splitting of tables on the basis of partnum
- From: Salman Qayyum
- Re: Splitting of tables on the basis of partnum
- From: Christian Knappke
- Re: Splitting of tables on the basis of partnum
- From: Salman Qayyum
- Splitting of tables on the basis of partnum
- Prev by Date: temp spaces filling up
- Next by Date: Re: Splitting of tables on the basis of partnum
- Previous by thread: Re: Splitting of tables on the basis of partnum
- Next by thread: Re: Splitting of tables on the basis of partnum
- Index(es):
Relevant Pages
|