Attribute change run taking more time

Hi Gurus
I am loading master data 0mat_plant everyday
nearly 2 to 3 lakhs record .The extracrion and loading is taking 30 min but attribute change run is taking 3 hrs .Is there any way to reduce attribute change run time.

Hi,
You can try going to the monitor for Attribute change run from RSA1 >> tools >> apply change run or from Transaction RSATTR which will schedule/display attribute change run. Here you can have an option called change run monitor (Monitor icon). this wil show the status of change run including which all info objects are affected, and if its hitting the aggregates of any cubes.
There are scenarios where the attribute change run failed with message that it was hitting/affecting aggregates of some infocubes. In case we had to switch off aggregates and trigger the change run again and then swtich on the aggregates after the change run is over. this may not be the exact issue you are facing.
And sometimes ACR goes on running for a long time in such case we need to check which Aggregate the ACR is currently changing and need to deactivate that aggregate.
But before deactivating an aggregate you need to check the data present in that and the usage of the aggregate.
Also you can try Tcode CHANGERUNMONI/program RSDDS_CHANGERUN_MONITOR to view this data.
Note 903886 - Hierarchy and attribute change run
thanks,
JituK

Similar Messages

Attribute Change run taking too long time to complete.

Hi all,
Attribute change run has been taking too long time to complete.It has to realign 50 odd aggreagates, some by delta , some by reconstruction. But inspite of all the aggregates it used to finish in quick time earlier. But since last 4-5 days it is taking indefinite time to finish.
Can anyone please suggest what all reasons may be causing this? and what possibly can be the solution to the problem? It is becoming a big issue. So kindly help with ur advises.
Promise to reward your answer liberally.
Regards,
Pradyut.

Hi,
Check with your functional owners in R/3 if there are mass changes/realignments or classification changes are going on regarding master data. e.g. reasigning materials to other material groups. This causes a major realignment in BW for all the aggregates. Otherwise check for parameterchanges / patches or missing db stats with your sap basis team.
Kind regards, Patrick Rieken.

Attribute Change Run taking very Long time.

Hi Experts:
We are daily loading Master data from one common process chain. There are 33 Infoobjects which are getting activated in Attribute Change Run Process. This process is taking almost 3 hours to run daily; due to this it is impacting our other data load process chains.
Many times it happens that there is lock on cubes due to attribute change as attributes are getting aligned to same cube on which the roll up is running.
There are local chains below the attribute change run, which are also important to run.
Please help and suggest the workaround for the same.
Cheers,
Omkar

33 info objects in one ACR(attribute change run) is not a good idea.
Better to split the info objects and use multiple ACR.
During your ACR if transaction data load was on then lock issues always occurs.
Thats why we need to run master data loads first and later transaction data loads.
Which info object change run was troubling, better to note the info objects which are causing and try to put them in separate ACR and trigger it before start of your transaction data loads. so that it won't raise the same issue again.

Hi i have 50 infoobjects as part of my aggregates and in that 10 infoobjects have received changes in masterdata.so in my process chain the Attribute change run in running for a long time.can i kill the job and repeat the same.

Hi i have 50 infoobjects as part of my aggregates and in that 10 infoobjects have received changes in masterdata.so in my process chain the Attribute change run in running for a long time.can i kill the job and repeat the same.

Hi,
I believe this would be your Prod system, so don't just cancel it but look at the job log. If it is still processing then don't kill it and wait for the change run to complete but if you can see that nothing is happening and it is stuck for a long time then you can go ahead and cancel it.
But please be sure, as these kind of jobs can create problems if you cancel them in the middle of a job.
Regards,
Arminder Singh

Attribute Change Run terminating - repeated several times - not locked

I had a failure in my master data chain tonight. The attribute change run that ran yesterday ran for 11k seconds and was cancelled (it says manually). When the chain ran tonight, the process failed again. I checked the log and it says "UNCAUGHT_EXCEPTION" and it created a short dump. I tried repeating to see if it did anything and it gave me the same message.
I went into the change run monitor and reset the status and manually tried to run the change run again. Same result "UNCAUGHT_EXCEPTION".
I then checked table RSDDAGGRMODSTATE and there was no blank CNSID entries, but there was a blank "completed flag" entry. I don't have change access to the table in prod so I cannot manually change it to X (meaning closed). I reset the status again in the chagne run monitor and the record with the blank "completed flag" disappeared. I repeated the change run and it failed again and a new record with the "completed flag" being blank appeared in the RSDDAGGRMODSTATE table.
I checked SM12 and there are no locks there. I'm on 7.0 so I can't manually right click on 0CUSTOMER and activate the master data either.
As a last resort I did run the function module RSDDS_AGGR_MOD_CLOSE but that short dumped too.
Any ideas? Please? This will fail my other chains that have 0CUSTOMER in the aggregates. Thanks.

HI,
Firstly try this FM RSDDS_AGGREGATES_MAINTAIN
if not possible
Try doing it manually
Uncaught exception may come due to many reasons
IN RSA1 go to tools and select attribute change run
Check the blog it shows you how to manually do attribute change run step by Step (for BI7.0 also)
/people/debjani.das/blog/2009/03/30/attribute-change-run-acr
Regards,
MADhu.
Edited by: MadhuMarupudi on Aug 21, 2009 5:49 AM

Log writer taking more time to write

Hi All,
we have oracle 10g(10.1.0) installed on rhel 5.3.. We are facing an issue regarding the logwriter..the logwriter is taking more time to write to the online redolog file...the trace file shows a warning message as " log writer time 840ms" ... Not sure what is the root cause of it..Please help me out in that regards..Thanks in advance...

imran khan wrote:
The archived log mode is disabled for the db..The online redolog files are not in FRA instead they are kept in diskgroups (multiplexed in two disk groups)..The controlfiles and datafiles are also stored in the same location as of online redolog files.The db is having the release as 10.2.0.4.0 and all the components are in 10.2.0.4.0 as well.
I also found that the ASM instance is having the release as 10.2.0.4.0(v$version view) but the compatibility attribute of the diskgroups is 10.1.0.0 . The compatible parameter in ASM instance shows 10.2.0.3.0 .
Do i need to change the compatibility of the diskgroups and the compatible parameter to 10.2.0.4.0 in ASM instance?
Not sure whether ASM compatibility makes any impact on delaying the lgwr to write to the online redolog files ?
Note : The online redolog files are stored in ASM diskgroups
please suggest...If your redo is in the same physical location as your datafiles, don't you think there might be some contention? (For my OLTP type of experience, undo is the most hit data file, too).
There could also be some more fundamental thing wrong, such as misconfigured I/O, and your redo just seems small. How often are they switching? Are you using hugefiles (as opposed to configuring them and unknowingly not using them)? Do you see any actual swapping to disk going on?
You likely have an OS I/O problem, but appear to only be looking at Oracle's view of it. What does the O/S say about it?
Are you sure you want to be running a production database without archive logging?

Attribut change run

HI,
I've one doubt about ACR.Since we deactivate all the aggregates and activate all the aggregates after attribute change run to speed up attribute change run whenevr we undergo system master data mass update?
Is this the correct way to handle this and another My question is if we are not loading any data in some xy cube but whenever we are doing mass update to master data we still deactivate that xy cubes aggregates and then activate the same.
Now if we are not laoding any data in the cubes then why we need to bother about aggregates of that particluar cube.I think we don't need to touch aggregates of that xy cube because we didn't loaded any new transaction data in it(Note cube already has previous years data ,I'm reffreing new data is not being loaded into cubes but this cube still being used in queries)
is this something related to historical records?
Can anybody clarifies my doubt?

Hi Rubane,
    Its like this, an ACR is used for updating master data changes. I'll try and explain with an example.
You have material in the cube and an attribute material group of material is switched on a navigational attribute.
Now since this is a navigational attribute, you can add it to an aggregate to improve your query performance.
Now a material group can be changed for a material at any given point of time.
say material X earlier had material group A but now has material group B.
In youe aggregate, you have all values corresponding to material X still assigned to material group A
eg aggregate Z
Material Group material key figure
A                      x            100
This is where an ACR comes into picture.
If you run an ACR for material, it activates the master data and then realligns the aggregate with any changes
So now your aggregate looks like this
Material Group material key figure
B                         x            100
So now to answer your question, yes we need to realign the aggregates even if the cubes are not being loaded. This is to take care of any master data changes that occur.
As for your second question, i do agree that its better to have aggregates with a '-' rather than none at all, since these help in the selection. Rather than selecting data from the cube, the query selects the data from the aggregate which is faster.
However the draw back of such aggregates if that they take a long time to fill. and nothing really changes i.e. very few records are summarized. I would suggest in your case, that you look at the aggregates and check the usage field. If you are continously activating and deactivating the aggregates, this really wont give you any idea. However you can still check this field. The more the value, the more times the aggregates is used.
Generally there are aggregates which have no usage at all. These can be deactivated which will save you some time.
Also check for the aggregates which are taking time. You can check the logs for the change run. You will see some values like /BIC/F**** where the ****** indicates the aggregate no. Go to table RSDDAGGRDIR and find the aggrcube field and enter this value. You will find the aggregate. You can then run some checks in RSRV for the cube. You can also try deactivating and then reactivating the aggregates. This will remove any inconsistency in the database for that aggregate which will save you time.
Regards.

Sql query is taking more time

Hi all,
db:oracle 9i
I am facing below query prob.
prob is that query is taking more time 45 min than earliar (10 sec).
please any one suggest me .....
SQL> SELECT MAX (tdar1.ID) ID, tdar1.request_id, tdar1.lolm_transaction_id,
2 tdar1.transaction_version
3 FROM transaction_data_arc tdar1
4 WHERE tdar1.transaction_name ='O96U '
5 AND tdar1.transaction_type = 'REQUEST'
6 AND tdar1.message_type_code ='PCN'
7 AND NOT EXISTS (
8 SELECT NULL
9 FROM transaction_data_arc tdar2
10 WHERE tdar2.request_id = tdar1.request_id
11 AND tdar2.lolm_transaction_id != tdar1.lolm_transaction_id
12 AND tdar2.ID > tdar1.ID)
13 GROUP BY tdar1.request_id,
14 tdar1.lolm_transaction_id,
15 tdar1.transaction_version;
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=17 Card=1 Bytes=42)
1 0 SORT (GROUP BY) (Cost=12 Card=1 Bytes=42)
2 1 FILTER
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'TRANSACTION_DATA_ARC
' (Cost=1 Card=1 Bytes=42)
4 3 INDEX (RANGE SCAN) OF 'NK_TDAR_2' (NON-UNIQUE) (Cost
=3 Card=1)
5 2 TABLE ACCESS (BY INDEX ROWID) OF 'TRANSACTION_DATA_ARC
' (Cost=5 Card=918 Bytes=20196)
6 5 INDEX (RANGE SCAN) OF 'NK_TDAR_7' (NON-UNIQUE) (Cost
=8 Card=4760)

prob is that query is taking more time 45 min than earliar (10 sec).Then something must have changed (data growth/stale statistics/...?).
You should post as much details as possible, how and what it is described in the FAQ, see:
*3. How to improve the performance of my query? / My query is running slow*.
When your query takes too long...
How to post a SQL statement tuning request
SQL and PL/SQL FAQ
Also, given your database version, using NOT IN instead of NOT EXISTS might make a difference (but they're not the same).
See: SQL and PL/SQL FAQ

Query is taking more time to execute in PROD

Hi All,
Can anyone tell me why this query is taking more time when I am using for single trx_number record it is working fine but when I am trying to use all the records it is not fatching any records and it is keep on running.
SELECT DISTINCT OOH.HEADER_ID
,OOH.ORG_ID
,ct.CUSTOMER_TRX_ID
,ool.ship_from_org_id
,ct.trx_number IDP_SHIPMENT_ID
,ctt.type STATUS_CODE
,SYSDATE STATUS_DATE
,ooh.attribute16 IDP_ORDER_NBR --Change based on testing on 21-JUL-2010 in UAT
,lpad(rac_bill.account_number,6,0) IDP_BILL_TO_CUSTOMER_NBR
,rac_bill.orig_system_reference
,rac_ship_party.party_name SHIP_TO_NAME
,raa_ship_loc.address1 SHIP_TO_ADDR1
,raa_ship_loc.address2 SHIP_TO_ADDR2
,raa_ship_loc.address3 SHIP_TO_ADDR3
,raa_ship_loc.address4 SHIP_TO_ADDR4
,raa_ship_loc.city SHIP_TO_CITY
,NVL(raa_ship_loc.state,raa_ship_loc.province) SHIP_TO_STATE
,raa_ship_loc.country SHIP_TO_COUNTRY_NAME
,raa_ship_loc.postal_code SHIP_TO_ZIP
,ooh.CUST_PO_NUMBER CUSTOMER_ORDER_NBR
,ooh.creation_date CUSTOMER_ORDER_DATE
,ool.actual_shipment_date DATE_SHIPPED
,DECODE(mp.organization_code,'CHP', 'CHESAPEAKE'
,'CSB', 'CHESAPEAKE'
,'DEP', 'CHESAPEAKE'
,'CHESAPEAKE') SHIPPED_FROM_LOCATION --'MEMPHIS' --'HOUSTON'
,ooh.freight_carrier_code FREIGHT_CARRIER
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)
+ NVL(XX_FSG_NA_FASTRAQ_IFACE.get_line_fr_amt ('FREIGHT',ct.customer_trx_id,ct.org_id),0)FREIGHT_CHARGE
,ooh.freight_terms_code FREIGHT_TERMS
,'' IDP_BILL_OF_LADING
,(SELECT WAYBILL
FROM WSH_DELIVERY_DETAILS_OE_V
WHERE -1=-1
AND SOURCE_HEADER_ID = ooh.header_id
AND SOURCE_LINE_ID = ool.line_id
AND ROWNUM =1) WAYBILL_CARRIER
,'' CONTAINERS
,ct.trx_number INVOICE_NBR
,ct.trx_date INVOICE_DATE
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('LINE',ct.customer_trx_id,ct.org_id),0) +
NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) +
NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)INVOICE_AMOUNT
,NULL IDP_TAX_IDENTIFICATION_NBR
,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) TAX_AMOUNT_1
,NULL TAX_DESC_1
,NULL TAX_AMOUNT_2
,NULL TAX_DESC_2
,rt.name PAYMENT_TERMS
,NULL RELATED_INVOICE_NBR
,'Y' INVOICE_PRINT_FLAG
FROM ra_customer_trx_all ct
,ra_cust_trx_types_all ctt
,hz_cust_accounts rac_ship
,hz_cust_accounts rac_bill
,hz_parties rac_ship_party
,hz_locations raa_ship_loc
,hz_party_sites raa_ship_ps
,hz_cust_acct_sites_all raa_ship
,hz_cust_site_uses_all su_ship
,ra_customer_trx_lines_all rctl
,oe_order_lines_all ool
,oe_order_headers_all ooh
,mtl_parameters mp
,ra_terms rt
,OE_ORDER_SOURCES oos
,XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V
WHERE ct.cust_trx_type_id = ctt.cust_trx_type_id
AND ctt.TYPE <> 'BR'
AND ct.org_id = ctt.org_id
AND ct.ship_to_customer_id = rac_ship.cust_account_id
AND ct.bill_to_customer_id = rac_bill.cust_account_id
AND rac_ship.party_id = rac_ship_party.party_id
AND su_ship.cust_acct_site_id = raa_ship.cust_acct_site_id
AND raa_ship.party_site_id = raa_ship_ps.party_site_id
AND raa_ship_loc.location_id = raa_ship_ps.location_id
AND ct.ship_to_site_use_id = su_ship.site_use_id
AND su_ship.org_id = ct.org_id
AND raa_ship.org_id = ct.org_id
AND ct.customer_trx_id = rctl.customer_trx_id
AND ct.org_id = rctl.org_id
AND rctl.interface_line_attribute6 = to_char(ool.line_id)
AND rctl.org_id = ool.org_id
AND ool.header_id = ooh.header_id
AND ool.org_id = ooh.org_id
AND mp.organization_id = ool.ship_from_org_id
AND ooh.payment_term_id = rt.term_id
AND xla_ael_sl_v.last_update_date >= NVL(p_last_update_date,xla_ael_sl_v.last_update_date)
AND ooh.order_source_id = oos.order_source_id --Change based on testing on 19-May-2010
AND oos.name = 'FASTRAQ' --Change based on testing on 19-May-2010
AND ooh.org_id = g_org_id --Change based on testing on 19-May-2010
AND ool.flow_status_code = 'CLOSED'
AND xla_ael_sl_v.trx_hdr_id = ct.customer_trx_id
AND trx_hdr_table = 'CT'
AND xla_ael_sl_v.gl_transfer_status = 'Y'
AND xla_ael_sl_v.accounted_dr IS NOT NULL
AND xla_ael_sl_v.org_id = ct.org_id;
-- AND ct.trx_number = '2000080';
}

Hello Friend,
You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
Please check the possbility of finding it through other AR tables.
2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
For example : For ra_cust_trx_types_all use ra_cust_trx_types.
This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
You can also check the same using
SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
If the tables are not analyzed , the CBO will not be able to tune your query.
4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
report.
Thanks,
Neeraj Shrivastava
[email protected]
Edited by: user9352949 on Oct 1, 2010 8:02 PM
Edited by: user9352949 on Oct 1, 2010 8:03 PM

Issue: attributes change run triggers the rebuilt of 0IC_C03 aggregates

Hello Guru,
I am facing to a problem that I don't understand.
Here is below the detail of the messages of a '3-infoobjects attributes change run' step of a Master Data process chain.
22:06:14     Job started
22:06:14     Step 001 started (program RSPROCESS, variant &0000000231235, user ID RFC_BW)
22:06:16     Starting process type ATTRIBCHAN with 3 objects...
22:06:16     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BICHNG_D8FC4Q04UD7NGLDMZ0QUBLX4K with ID 22061600
22:06:16     Editing of aggregate 100139; background job BICHNG_D8FC4Q04UD7NGLDMZ0QUBLX4K; start time 22:06:16/07.07.2010
22:06:18     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BICHNG_D8FC4Q04UD7NGLDMZ0QUBLX4K with ID 22061601
22:06:18     Editing of aggregate 100143; background job BICHNG_D8FC4Q04UD7NGLDMZ0QUBLX4K; start time 22:06:18/07.07.2010
23:02:29     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BICHNG_D8FC4Q04UD7NGLDMZ0QUBLX4K with ID 23022900
23:02:29     Editing of aggregate 100140; background job BICHNG_D8FC4Q04UD7NGLDMZ0QUBLX4K; start time 23:02:29/07.07.2010
23:52:38     Starting process type MDHIERACT with 2 objects...
23:52:39     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BIACTI_D8FCR9Y1NWOP2T4F76FYE0HDG with ID 23523900
23:52:39     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BIACTI_D8FCR9Y1NWOP2T4F76FYE0HDG with ID 23523901
23:53:10     Aggregate 100139: Repair indexes
23:57:14     Aggregate 100140: Repair indexes
00:17:23     Aggregate 100143: Repair indexes
00:50:09     3 aggregates are condensed
00:50:09     Starting process type CONDAGGR with 3 objects...
00:50:10     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BICOND_D8FD3GTNF0KF92R34346SW6PG with ID 00501000
00:50:10     Editing of aggregate 100143; background job BICOND_D8FD3GTNF0KF92R34346SW6PG; start time 00:50:10/08.07.2010
00:50:10     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BICOND_D8FD3GTNF0KF92R34346SW6PG with ID 00501001
00:50:10     Editing of aggregate 100140; background job BICOND_D8FD3GTNF0KF92R34346SW6PG; start time 00:50:10/08.07.2010
00:50:16     Program RSBATCH_EXECUTE_PROZESS successfully scheduled as job BICOND_D8FD3GTNF0KF92R34346SW6PG with ID 00501600
00:50:16     Editing of aggregate 100139; background job BICOND_D8FD3GTNF0KF92R34346SW6PG; start time 00:50:16/08.07.2010
00:50:22     Hierarchy/attribute change successfully carried out
00:50:23     Event RSPROCESS with parameter D59BE8XWZMHY0IFP2VLEFP671 successfully triggered
00:50:23     Job finished
As you can observe, the step takes almost 3 hours !!!!!!! After anlyses BICHNG_* concerns
22:06:16 Job started
22:06:16 Step 001 started (program RSBATCH_EXECUTE_PROZESS, variant &0000000891873, user ID RFC_BW)
22:06:18 Aggregate 100139( 0IC_C03) is being adapted / rebuilt
22:06:18 Statistic UID of the aggregate process: 'D8FC4Q9KSAMRDWQ1RDPPKMF3O' (RSDDSTATAGGR)
22:06:27 Aggregate 100139: Read (1) from table /BI0/E0ICC03_ (max 500000 records)22:06:27 SQL: 07.07.2010 22:06:27 RFC_BW
I don't understand what is the link between the '3-infoobjects attributes change run' (BBATCH, 0MAT_SALES, 0MAT_PLANT) and the rebuilt of 3 0IC_C03 (Material Stocks/Movements) aggregates (why does the 'attribute chan run' trigger the rebuit of aggregates???).
The rebuilt of the 3 aggregates takes 1 416, 3 366, 3 009 secondes...
Does anyone understand my problematic? If not I can give you more details.
Thanks in advance for your help.
Samuel

1/ Exactly Fred
Here is the definitions of the aggregate:
100139:
0PLANT
0STOR_LOC
0MAT_PLANT__0VAL_CLASS
0STOCKCAT
0STOCKTYPE
BMODIFIC
BMVTSTOCK
0MATL_TYPE
0CALxxx
2/ For my information in the aggregate 100140 , does the presence of BBATCH (one of the 3 IO) trigger the rebuilt or is it only 0MAT_PLANT__0VAL_CLASS ?
100140:
0PLANT
0STOR_LOC
0MATERIAL
0MAT_PLANT__0VAL_CLASS
BBATCH
0STOCKCAT
0STOCKTYPE
BMODIFIC
BMVTSTOCK
0MATL_TYPE
0CALxxx
3/ In the same process chain, I have another Attributes Change Run: 0MATERIAL. Several active aggregates using 0MATERIAL__0MATL_TYPE are built on a CO-PA cube.
Why did the '0MATERIAL Attributes Change Run' rebuild no aggregate? (see below)
22:06:04     Job started
22:06:04     Step 001 started (program RSPROCESS, variant &0000000231238, user ID RFC_BW)
22:06:06     Activation of master data for 0MATERIAL
22:06:07     154 Data records deleted
22:06:11     154 Data records deleted
22:06:12     154 Data records updated
22:06:13     154 Data records updated
22:06:13     0 aggregates are condensed
22:06:14     Hierarchy/attribute change successfully carried out
22:06:14     Event RSPROCESS with parameter D59BEEE069HKRCRU0ZPYFUPB1 successfully triggered
22:06:14     Job finished
Samuel

Issue with background job--taking more time

Hi,
We have a custom program which runs as the background job. It runs every 2 hours.
Itu2019s taking more time than expected on ECC6 SR2 & SR3 on Oracle 10.2.0.4. We found that it taking more time while executing native SQL on DBA_EXTENTS. When we tried to fetch less number of records from DBA_EXTENTS, it works fine.
But we need the program to fetch all the records.
But it works fine on ECC5 on 10.2.0.2 & 10.2.0.4.
Here is the SQL statement:
EXEC SQL PERFORMING SAP_GET_EXT_PERF.
SELECT OWNER, SEGMENT_NAME, PARTITION_NAME,
         SEGMENT_TYPE, TABLESPACE_NAME,
         EXTENT_ID, FILE_ID, BLOCK_ID, BYTES
   FROM SYS.DBA_EXTENTS
   WHERE OWNER LIKE 'SAP%'
   INTO
   : EXTENTS_TBL-OWNER, :EXTENTS_TBL-SEGMENT_NAME,
   :EXTENTS_TBL-PARTITION_NAME,
   :EXTENTS_TBL-SEGMENT_TYPE , :EXTENTS_TBL-TABLESPACE_NAME,
   :EXTENTS_TBL-EXTENT_ID, :EXTENTS_TBL-FILE_ID,
   :EXTENTS_TBL-BLOCK_ID, :EXTENTS_TBL-BYTES
ENDEXEC.
Can somebody suggest what has to be done?
Has something changed in SAP7 (wrt background job etc) or do we need to fine tune the SQL statement?
Regards,
Vivdha

Hi,
there was an issue with LMT's but that was fixed in 10.2.0.4
besides missing system statistics:
But WHY do you collect every 2 hours this information? The dba_extents view is based on really heavy used system tables.
Normally , you would start queries of this type against dba_extents ie. to identify corrupt blocks and such:
SELECT owner , segment_name , segment_type
        FROM dba_extents
       WHERE file_id = &AFN
         AND &BLOCKNO BETWEEN block_id AND block_id + blocks -1
Not sure what you want to achieve with it.
There are monitoring tools (OEM ?) around that may cover your needs.
Bye
yk

Level1 backup is taking more time than Level0

The Level1 backup is taking more time than Level0, I really am frustated how could it happen. I have 6.5GB of database. Level0 took 8 hrs but level1 is taking more than 8hrs . please help me in this regard.

Ogan Ozdogan wrote:
Charles,
By enabling the block change tracking will be indeed faster than before he have got. I think this does not address the question of the OP unless you are saying the incremental backup without the block change tracking is slower than a level 0 (full) backup?
Thank you in anticipating.
OganOgan,
I can't explain why a 6.5GB level 0 RMAN backup would require 8 hours to complete (maybe a very slow destination device connected by 10Mb/s Ethernet) - I would expect that it should complete in a couple of minutes.
An incremental level 1 backup without a block change tracking file could take longer than a level 0 backup. I encountered a good written description of why that could happen, but I can't seem to locate the source at the moment. The longer run time might have been related to the additional code paths required to constantly compare the SCN of each block, and the variable write rate which may affect some devices, such as a tape device.
A paraphrase from the book "Oracle Database 10g RMAN Backup & Recovery"
"Incremental backups must check the header of each block to discover if it has changed since the last incremental backup - that means an incremental backup may not complete much faster than a full backup."
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

PGI Taking more time approximate 30 to 45 minutes

Dear Sir,
While doing post goods issue against delivery document system is taking lots of time, this issue is very very urgent can any one resolved or provide suitable solution for solving this issue.
We creates every day approximate 160 sales order / delivery and goods issue against the same by using transaction code VL06O system is taking more time for PGI.
Kindly provide suitable solution for the same.
Regards,
Vijay Sanguri

Hello Vijay,
I've just found the SAP Note 1459217 which definitively refers to your issue. Please have a look on it (see below the respective SAP note text).
In case you have question let me know!
Best Regards,
Marcel Mizt
Symptom
Long runtimes occur when using transaction VL06G or VL06O in order to post goods issue (PGI) deliveries.
Poor response times occur when using transaction VL06G or VL06O in order to PGI deliveries.
Poor performance occurs with transaction VL06G / VL06O.
Performance issues occur with transaction VL06G / VL06O.
Environment
SAP R/3 All Release Levels
Reproducing the Issue
Execute transaction VL06O.
Choose "For Goods Issue". (Transaction VL06G).
Long runtimes occur.
Cause
There are too many documents in the database that need to be accessed.
The customising settings in the activity "set updating of partner index" are not activated.
(IMG -> Logistics Execution -> Shipping -> Delivery List -> Set Updating Of Partner Index).
Resolution
If there are too many documents in the database to access, archiving them improves the performance of VL06G.
The customising settings in the activity "set updating of partner index" can be updated to improve the performance of VL06G. (IMG -> Logistics Execution -> Shipping -> Delivery List -> Set Updating Of Partner Index). In this transaction, check the entries for the transaction group 6 (= delivery). The effect of these settings is that the table VLKPA (SD index: deliveries by partner functions) is only filled with entries based on the partner functions listed (for example WE = ship-to party). In transaction VL060 the system is checking this customising in order to access the table VBPA or VLKPA.
If you change the settings of the activity "updating of partner index", run the report RVV05IVB to reorganize the index seleting only partner index in the delivery section of the screen. (see note 128947).
Flag the checkbox "display forwarding agent" (available in the display options section of the selection screen). When the list is generated, use the "set filter" functionality (menu path: edit -> set filter) in order to select the deliveries correspondng to one forwarding agent.

Admin server taking more time to start

Hi All,
I installed OIM 11g R2 in windows server2008 ,
while starting the admin server it is taking the more time, .
Steps i have done.
changed memory parameters for setSOADomainEnv, setOIMDomainEnv, oimenv.bat files.
while starting the admin server it is showing the memory parameters are Xms768m.....xms1024m like that.
can anyone please suggest what changes needs to do to run fast
Thanks,
Valli

user623166 wrote:
Hi Gurus
my database oracle 10.2.0.3 in AIX
I have started expdp to export selective around 130 tables but it is taking more time to start , almost 20 min passed since it start.
$ expdp system/*** parfile=parfile.par
Export: Release 10.2.0.3.0 - 64bit Production on Friday, 22 June, 2012 17:21:26
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
Starting "SYSTEM"."SYS_EXPORT_TABLE_02": system/******** parfile=parfile.par
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
I am not sure that this is enough information for us to suggest something. For starters, can you try selecting less tables than 120 and see what's going on?
Aman....

Attribute change run Failing in Process Chain

Hi guys,
Every day my process chains is failing due to Attribute change run and I am maually running attribute change run.
And one more thing when the attr. change run is triggered automatically,then it is generating 2 change counters in RSATTR tcode instead of 1.
One is successfully completes and one is still in schedule.After 2days days it is showing like completed change count id.
Please help me.
Regards,
Tiragati.

Hi,
As you said Attribute change run step is failing every day.
can you post the error message. is it failing because of Lock issue or some other issue.
Mostly attribute change runs fails with lock issues. if its the same problem in your case. make sure that no master data objects runs at the time attribute change run runs.
Try to put some delay in the process of the Attribute change run so that it will not get failed.
Check if its the same ACR scheduled or diff objects?
Regards
KP

Attribute change run taking more time

Similar Messages

Maybe you are looking for