After table partition, some transactions hang

Question

I am running SAP 4.6 and Oracle 10.2
I recently used online reorg to partition table DFKKOP (over 100 million records) into two parts.  One partition was for "closed" orders, and the other was for "open" orders (less than 2% of the rows). 
Since most of the queries against this table were against open orders, access times improved dramatically (one query went from 20 minutes to 20 seconds).
Unfortunately, while it was on a test system, our developers discovered that this caused transactions FPL9 and CIC0 to hang.  To prove that it was the partition causing the hang, we used our "snapback" ability to return the database to the point in time prior to the partition (we did this twice), and the problem disappeared.  Other than these hangs, the database seemed to work normally.
Does anyone have an idea why this might be happening?  BTW - I had "row movement enabled", so that's not it.  I have found nothing in SAP notes or on this forum.
Thanks.

Answer 1

>
Sandeep Pasumarti wrote:
> i am also thinking of partitioning a large table - custom table - that we use instead of glpca.. it is 40gb..would you happen to have a how-to approach in doing that? how did you handle the abap dictionary side? - or do you just do on oracle...thanks!
>
> ps i was thinking on doing something fiscal year.. or acct number range...not sure how i could partition FY for years moving forward...meaing fy 2002 is one partition, 2003 is another, etc...
Hi Sandeep,
Partitioning is a really cool feature - but it must be valued against your primary goal you want to achieve.
it has an influence WICH partitioning method you have to use AND wich partitioning keys you have to find.
If you see it like a triangle you can have these goals:
                               Performance
     Administration                                  Availability
you will hardly achieve all three (wich means you generate some overhead for the other goals).
It may that you are in a corner of one goal - see the location of (*) 
Our goal was improve write performance (in the 1st place):
We did it on a SAP BW system on our own Z tables wich were growing bigger and bigger ( several hundreds of GBytes). As we debugged how BW itself managed the partitions we used this and a little ABAP to maintain the partitions for our own tables.
Our's was range partitioning with an  Identifier (INT4) used as a sequence to flagg present and historical calculations as a partition key. We could now TRUNCATE the partitions instead of  DELETE (the UNDO generation blew up our batch time window for computations of figures).
And yes we benefit from partion pruning - as far you had a lot of full table scans wich are now turned into partition scans. Index accesses benefit not that muxch from paritioning -  but it reallly depends on your application HOW it uses the data.
All your queries should  use  the partition key as a criteria (in your case FISCYEAR) - otherwise you make things worse.
Be aware that you have to use the right data type (imagine a range partiton on a Varchar2 column
like the NUMBER data type in SAP tables) and evaluate it carefully against the partiton type you choose.
There are some pitfalls like moving partition keys (wich you have to avoid ).
There is the overhead of creating / dropping/ merging partitions and who is responsible for it (in our case
the application and not an SAP admin).
Maintain all indexes as local
You can use BRSPACE to partition the table , with your 40 Gybte SE14 could be also used as you can define the partitions (hopefully you are at least on a 6.20 system).
For our system it was essential
1) to fully understand the concept of partitioining (seems obvious, but guess where things most fail)
2 that it is supported by standard SAP tools (as in SE14 or BRSPACE)
3) to write an interface to handle the partitioning without involving a DBA
(imagine you have a process chain that uses your partition table and you have to provide a new partition while running the chain).
We run it now for more than a year and it was a good decision to move to partitioning.
Now we will extend the feature and use it for archivals on a partition basis.
Bye
yk