OAI_AGENT_ERROR table growing rapidly

Hi
I have a problem with my oai_agent_error table growing at a rate of a 1000 records every few minutes. My DB adapter reports the following error before dropping the messages,
oracle.oai.agent.server.transform.database.DBTransformationException: PLSQLTransformation.transform: Transformation failed
at oracle.oai.agent.server.transform.database.PLSQLTransformation.transform(PLSQLTransformation.java:359)
at oracle.oai.agent.server.transform.BuiltInTransformation.transform(BuiltInTransformation.java:293)
at oracle.oai.agent.server.transform.MessageTransformer.processStackFrame(MessageTransformer.java:849)
at oracle.oai.agent.server.transform.MessageTransformer.processTransformMetadatalet(MessageTransformer.java:489)
at oracle.oai.agent.server.transform.MessageTransformer.transformMessage(MessageTransformer.java:276)
at oracle.oai.agent.server.InMessageTransformer.processObject(InMessageTransformer.java:87)
at oracle.oai.agent.common.QueueAgentComponent.run(QueueAgentComponent.java:110)
at java.lang.Thread.run(Thread.java:534)
We have a custom PL/SQL package that does the AV to CV transforms for us and this is valid at the moment.
I also see that its not all messages that are getting dropped as some messages have reached my Spoke systems properly transformed.
I would really like to know how to debug this further to stop these messages from being dropped.
Any help is much appreciated!
Thank you

HI
"oracle.oai.agent.server.transform.database.DBTransformationException: PLSQLTransformation.transform: Transformation failed" in the log file means this error occured at agent level /application level.So,using metadata interconnect is not able to convert input data in to application view.
Error is transformation failed.So reason can be
--> any unhandled exceptions
--> mismatch in data type of fields/parameters used.
--> mis match in number of field/elements in input data.
Transformation failed indicates interconnect not able to transform input data in to sepcified format in Application view or common view.
As you mentioned,this is happening only with few records.
--> check if failed records are to test negative cases.
--> check if failed records have all values expected as mandatory for transformation.
--> check if failed records have the data with expected datatypes(For eg field a is defined as number and field a in record have value 'abc' instea dof 123).
Hope this information helps you.

Similar Messages

  • WF_ITEM_ACTIVITY_STATUSES_H table is growing rapidly in PROD.

    Hi,
    We are noticing one of the table WF_ITEM_ACTIVITY_STATUSES_H size was 6 GB on 20-APR-11. Today it is at 25 GB (in 1 month) with 356 million rows and growing rapidly! any idea.
    Thanks
    Rao

    I have one question for you. How to purge the workflow date where item_type(OEOH,OEOL) specific only. I would really appreciate if you can guide us in the right direction this issue is becoming more and more critical to the business and also it's degrading the whole back groung process too.
    Righ now in prod we are running the "Purge Obsolete Workflow Runtime Data" 21 days Temporary:Y:500:N. i checked the count fro OEOL and OEOH by using below query
    select item_type, count(*)
    from WF_ITEM_ACTIVITY_STATUSES_H group by item_type
    OEOL14982271 14 Million
    OEOH504495652 510 Million
    select count(*) from WF_ITEM_ACTIVITY_STATUSES_H;
    519793016 519 million
    Thanks
    Ganga

  • PSAPUNDO Table space growing rapidly

    Hello
    The tablespace PSAPUNDO is growing rapidly on one of client server how to .
    PSAPUNDO     1,736.13     151.2
    PSAPUNDO     441.125     42.6
    PSAPUNDO     183.125     15
    PSAPUNDO     142.125     12.6
    PSAPUNDO     81.125     5.9
    PSAPUNDO     74.125     3.3
    PSAPUNDO     44.125     1.9
    PSAPUNDO     35.125     1.7
    PSAPUNDO     39.125     0.3
    PSAPUNDO     20.125     0.3
    this growth in six days...? can any one help me as im new to sap

    letzfriend wrote:
    Hello
    >
    > The tablespace PSAPUNDO is growing rapidly on one of client server how to .
    >
    > PSAPUNDO     1,736.13     151.2
    > PSAPUNDO     441.125     42.6
    > PSAPUNDO     183.125     15
    > PSAPUNDO     142.125     12.6
    > PSAPUNDO     81.125     5.9
    > PSAPUNDO     74.125     3.3
    > PSAPUNDO     44.125     1.9
    > PSAPUNDO     35.125     1.7
    > PSAPUNDO     39.125     0.3
    > PSAPUNDO     20.125     0.3
    >
    >
    > this growth in six days...? can any one help me as im new to sap
    Hi,
    Did you check the note 1035137 - Oracle Database 10g: Automatic Undo Retention?
    Best regards,
    Orkun Gedik

  • SYSAUX Growing Rapidly

    Hi,
    When i configured IC mode the SYSAUX Growing Rapidly.
    Please let me know what happens.
    Thank

    Hello,
    Seems like the log mining server has grow this tables due any reason. May be the execution of a large transacction, a massive UPDATE, DELETE or INSERT.
    Once these tables have grown, no free space.
    Would have to test whether making a shutdown / startup instance these tables are truncated. Since the information they hold, I think, would only be necessary for the Log Miner session.
    Which is the result of this queries:
    SELECT COUNT(*) FROM SYSTEM.LOGMNRC_GTCS  ;
    SELECT COUNT(*) FROM SYSTEM.LOGMNR_COL$ ;
    You can confirm that there is no transaction in the database for long term? You can look at the view v $ TRANSACTION, has a column that specifies the date and time when a transaction began.
    From MOS:
    There is no official way to reclaim the space but as a workaround you can use the DBMS_LOGMNR_D.SET_TABLESPACE routine to recreate all LogMiner tables in an alternate tablespace. For example, the following statement will recreate all LogMiner tables to use the LOGMNRTS tablespace:
    From MOS.
    How to Reclaim Space Used by LogMiner Tables (Doc ID 456814.1)
    SQL> connect / as sysdba
    SQL> EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE ('LOGMINER_DATA');
    However this command requiere stop GG capture process.
    This procedure move the Logminer tables to the tablespace indicated, then, in the move operation the space is compacted.
    May be a good practice using GG IC is to define a dedicated tablespace to Logminer.
    I hope help.
    Regards
    Arturo

  • PSAPSID tablespace grows rapidly

    Hi All,
    We are having a BI7[SP11] system on oracle. All were normal operations till the 1 month past. This month, we have been observing that the PSAP<SID> tbspc has been growing rapidly very much. When checked with functionals no extra loads were used.
    Now I can monitor from DB02 on the tbspc by checking the history, when more delta occured, but I wanted to see which table, related to which data, all that delta happened, so that i can check with functionals.
    Is there anyway to still dig this and get the proof. Can any body please help..
    Thanks a lot
    VR.

    Hi Vera,
    I would recommend to you if you wish to see the table, via the table space name, in transaction DB02, and then relate that to the table in your BW system.
    I would use the following steps
    Monitor in DB02 and then get your table space name
    Under DB02 you should see under the "Space" drill down a option called "Tables and Indexes" double click on this option
    Hopefully your basis team would of Reorged the tables so you have the latest stats
    Hit continue then enter your table space name as selection criteria
    From here you can get the table space name,
    Take your table space name and enter this into the table SE16 RSTSODS you should be able to get the generic PSA name that is being wrote to
    Other wise if it is not in this table you should have a very good idea of what sort of data is being recorded by the naming convention.
    Thanks
    Ben
    **Please assign points if helpful**

  • Writing to BLOB gets slow as table grows

    Hi,
    We have a table with a BLOB column. When the table is empty it takes a few second to insert 3k rows. As the table grows to 500k rows, it takes almost 5 minutes to insert the same # of rows, and it's getting slower and slower. At the beginning, I thought it was because of indexes and constraints, so I disabled all foreign key constraints (have to leave primary keys and indexes there), it doesn't make much difference. I don't see other tables with indexes and constraints and even more # of rows but w/o BLOB column have such significant performance degradation. The BLOB is stored out of line in a separate tablespace with 8k block size and chunk size.
    Do you have any idea what may cause the slowness in insert?
    Thanks.

    If the tablespace is ASSM (segment space management AUTO), there are issues with LOB performance. If you can, move the table and it's LOB to an MSSM tablespace and re-test your inserts.
    BTW, what version and patchlevel are your running ?

  • Table grows to 6 GB with 6k records only after Delete ORA-01653:

    Hello,
    I have a Table that i delete data from using
    DELETE FROM DJ_20255_OUTPUT a where trunc(a.LOADED_DATE) <trunc(sysdate -7);
    COMMIT;
    the issue i have is when i want to repopulate the table i get the Error ORA-01653: unable to extend table.
    The table grows to over 6gb but if i truncate that table and in both cases there is no data left in the table after either action the table will only grow to 0.8 Mb once populated.
    so with truncate table size is 0.8MB and if i use delete from.... the table grows to 6GB
    The repopulation of the table uses mutiple insert statments commiting after each one.
    is this a bug or is there an action i should perform onece I have deleted the data?
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi

    Is this an Index Organized table ? (select IOT_TYPE from user_tables where table_name = 'DJ_20255_OUTPUT' ;)
    Are you saying that you use this sequence :
    DELETE .... in one single call to delete all the rows
    INSERT ... in multiple calls with COMMIT after each row
    Hemant K Chitale

  • Disadvantages of letting FACTFINANCE table grow bigger day by day?

    Hi All,
    Please share your inputs on the Disadvantages and Advantages of letting FACTFINANCE table grow bigger day by day.
    As far as i know there's no theoretical limit to the number of records.
    If there is any solution or process followed to keep only actively used data records in FACTFINANCE and smart way in dealing with very rarely used data (Historical data).
    Please suggest/comment it will greatly help us!
    Regards,
    Rajesh Muppala.

    The main disadvantage of a huge factfinance table will be initially the process time of changing a dimension hierarchy. I have heard of processing taking 8 hours when a large fact table is involved. I am not sure of a theoretical limit. I suspect the limit will be more of the operating system limits rather than SQL server limits.
    Of course performance will slow when the fact table gets large to. So archiving off historic ( and not used) data is a good idea.
    To create a system where only actively used records are kept would need to be a custom procedure where you;d need to analyse the queries coming from the client side. It seems a very complex method that could land up with errors and dad corruption.
    I personally would rather make a business decision about it and archive a few years off into a separate application set. In an ideal world, it could be on a separate server as well so the productions system is not affected in any way.
    Another option would be to make custom partitions in the finance cube. This would mean the same fact table is used but different partitions for each year (for example).
    Tim

  • APPS_TS_MEDIA tablespace growing rapidly

    Hi,
    The APPS_TS_MEDIA tablespace stores all the attached documents in Oracle Applications. But it is growing at a very rapid rate.
    Is there a way to delete the old attachments from this tablespace?
    When users raise a PO/PR, they attach the document along with the PR. But once the PR is closed, we no longer require those attachments.
    Could someone please let me know if there is any way of deleting those old files from APPS_TS_MEDIA tablespace?
    Thanks!

    OWNER     SEGMENT_NAME          SEGMENT_TYPE     SIZ
    APPLSYS     SYS_LOB0000057442C00004$$     LOBSEGMENT     53,561,262,080
    APPLSYS     FND_LOBS               TABLE          114,294,784
    APPLSYS     SYS_IL0000057442C00004$$     LOBINDEX     22,544,384
    APPLSYS     FND_LOBS_N1          INDEX          2,359,296
    APPLSYS     FND_LOBS_U1          INDEX          2,097,152
    CSF     CSF_MD_LYR_METADATA     TABLE          131,072
    CSF     CSF_MD_RD_SEGS          TABLE          131,072
    CSF     CSF_TDS_BINARY_TILES     TABLE          131,072
    CSF     CSF_TDS_SEGMENTS          TABLE          131,072
    CSF     SYS_IL0000060656C00011$$     LOBINDEX     131,072
    CSF     SYS_IL0000061938C00007$$     LOBINDEX     131,072
    CSF     SYS_IL0000061011C00013$$     LOBINDEX     131,072
    CSF     SYS_LOB0000060628C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060628C00011$$     LOBSEGMENT     131,072
    CSF     CSF_LF_ROADSEGMENTS     TABLE          131,072
    CSF     CSF_MD_RAIL_SEGS          TABLE          131,072
    CSF     SYS_IL0000060656C00010$$     LOBINDEX     131,072
    CSF     SYS_IL0000061068C00016$$     LOBINDEX     131,072
    CSF     SYS_IL0000061938C00008$$     LOBINDEX     131,072
    CSF     SYS_IL0000209418C00012$$     LOBINDEX     131,072
    CSF     SYS_IL0000060957C00013$$     LOBINDEX     131,072
    CSF     SYS_IL0000061112C00011$$     LOBINDEX     131,072
    CSF     SYS_IL0000060704C00011$$     LOBINDEX      131,072
    QP     QP_DOCUMENTS_U1          INDEX          131,072
    CSF     SYS_LOB0000060588C00018$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060869C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061979C00003$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000062083C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209422C00011$$     LOBSEGMENT     131,072
    CSF     CSF_LF_NAMES          TABLE          131,072
    CSF     CSF_LF_PLACE_NAMES          TABLE          131,072
    CSF     CSF_LF_POIS          TABLE          131,072
    CSF     CSF_LF_ROADSEGM_PLACES     TABLE          131,072
    CSF     CSF_MD_INST_STYLE_SHTS     TABLE          131,072
    CSF     CSF_MD_NAMES          TABLE          131,072
    CSF     CSF_TDS_ROADBLOCKS     TABLE          131,072
    CSF     CSF_MD_OM_ROADS          TABLE          131,072
    CSF     SYS_IL0000061938C00005$$     LOBINDEX      131,072
    CSF     SYS_IL0000061068C00017$$     LOBINDEX 131,072
    CSF     SYS_IL0000060588C00018$$     LOBINDEX      131,072
    FRM     SYS_IL0000285924C00004$$     LOBINDEX      131,072
    CSF     SYS_LOB0000060588C00017$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060656C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060656C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060704C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061068C00016$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061938C00005$$     LOBSEGMENT     131,072
    CSF     CSF_LF_PLACES          TABLE          131,072
    CSF     CSF_LF_POI_NAMES          TABLE          131,072
    CSF     CSF_LF_ROADSEGM_POSTS     TABLE          131,072
    CSF     CSF_MD_LAND_USES          TABLE          131,072
    CSF     CSF_MD_POI_NM_ASGNS     TABLE          131,072
    CSF     CSF_MD_THEME_METADATA     TABLE          131,072
    CSF     CSF_TDS_CONDITIONS     TABLE          131,072
    CSF     CSF_TDS_TILES          TABLE          131,072
    CSF     CSF_MD_OM_POIS          TABLE          131,072
    FRM     FRM_REPOSITORY_LOBS     TABLE          131,072
    CSF     SYS_IL0000060588C00017$$     LOBINDEX      131,072
    CSF     SYS_IL0000061979C00004$$     LOBINDEX      131,072
    CSF     SYS_IL0000062083C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000209418C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000209420C00012$$     LOBINDEX      131,072
    CSF     SYS_IL0000061112C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000060704C00012$$     LOBINDEX      131,072
    CSF     SYS_LOB0000060897C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061011C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061112C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061156C00028$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061938C00008$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000062261C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209418C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209422C00010$$     LOBSEGMENT     131,072
    CSF     CSF_LF_ROADSEGM_NAMES     TABLE          131,072
    CSF     CSF_MD_ADM_BOUNDS     TABLE          131,072
    CSF     CSF_MD_HYDROS          TABLE          131,072
    CSF     CSF_TDS_BINARY_MAPS     TABLE          131,072
    CSF     CSF_TDS_NODES          TABLE          131,072
    CSF     CSF_TDS_RDBLCK_INTVLS     TABLE          131,072
    CSF     SYS_IL0000062083C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000060628C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000061011C00012$$     LOBINDEX      131,072
    CSF     SYS_IL0000209422C00010$$     LOBINDEX      131,072
    CSF     SYS_IL0000060957C00012$$     LOBINDEX      131,072
    CSF     SYS_LOB0000060897C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060957C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060957C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061011C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061938C00007$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061979C00004$$     LOBSEGMENT     131,072
    QP     SYS_LOB0000296934C00002$$     LOBSEGMENT     131,072
    CSF     CSF_MD_LYR_STYLE_SHTS     TABLE          131,072
    CSF     CSF_TDS_COND_SEGS          TABLE          131,072
    CSF     CSF_TDS_INTERVALS          TABLE          131,072
    CSF     SYS_IL0000061979C00003$$     LOBINDEX      131,072
    CSF     SYS_IL0000060628C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000060869C00013$$     LOBINDEX      131,072
    CSF     SYS_IL0000061156C00028$$     LOBINDEX      131,072
    CSF     SYS_IL0000061156C00029$$     LOBINDEX      131,072
    CSF     SYS_IL0000209424C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000209420C00011$$     LOBINDEX      131,072
    CSF     SYS_IL0000060897C00012$$     LOBINDEX      131,072
    CSF     SYS_IL0000060897C00013$$     LOBINDEX      131,072
    CSF     SYS_IL0000062261C00014$$     LOBINDEX      131,072
    CSF     SYS_LOB0000061938C00006$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209424C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209424C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209420C00012$$     LOBSEGMENT     131,072
    FRM     SYS_LOB0000285924C00004$$     LOBSEGMENT     131,072
    CSF     CSF_MD_POIS          TABLE          131,072
    CSF     CSF_MD_RDSEG_NM_ASGNS     TABLE          131,072
    CSF     CSF_MD_OM_HYDROS          TABLE          131,072
    CSF     SYS_IL0000061938C00006$$     LOBINDEX     131,072
    CSF     SYS_IL0000060869C00012$$     LOBINDEX     131,072
    CSF     SYS_IL0000062261C00013$$     LOBINDEX     131,072
    FRM     FRM_REPOSITORY_LOBS_N1     INDEX          131,072
    QP     SYS_IL0000296934C00002$$     LOBINDEX     131,072
    CSF     SYS_LOB0000060704C00012$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000060869C00013$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061068C00017$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061112C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000061156C00029$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209418C00011$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000209420C00011$$     LOBSEGMENT     131,072
    CSF     CSF_LF_PLACE_POSTCS     TABLE          131,072
    CSF     CSF_LF_POSTCODES          TABLE          131,072
    CSF     CSF_TDS_RDBLCK_SGMNTS     TABLE          131,072
    CSF     CSF_TDS_SEGM_NODES     TABLE          131,072
    CSF     CSF_MD_OM_ADMINS          TABLE          131,072
    QP     QP_DOCUMENTS          TABLE          131,072
    CSF     SYS_IL0000209424C00010$$     LOBINDEX     131,072
    CSF     SYS_IL0000209422C00011$$     LOBINDEX     131,072
    FRM     FRM_REPOSITORY_LOBS_UK1     INDEX          131,072
    CSF     SYS_LOB0000062083C00010$$     LOBSEGMENT     131,072
    CSF     SYS_LOB0000062261C00014$$     LOBSEGMENT     131,072
    I looked into thoe MOS, but nothing seems to help!
    I have raised a TAR with Oracle and they say, this functionality of deleting attachment doesnt exist and they are finding a solution for it.
    Thanks!

  • Temporay tablespace grows rapidly. . .

    Dear All,
    When I run a large query the temporary tablespace grows continuously.
    The max size of temporary tablespace is 6G.
    I set Autoextend on, next size is 10m and maxsize is 6291456M.
    Also I set the SORT_AREA_SIZE = 256m.
    How to stop the rapid growth of temporary tablespace.
    Thanks in advance,
    PratHamesh.

    If your Oracle version is 9i you can set your PGA_AGGREGATE_TARGET into a appropriate value(i.e. PGA_AGGREGATE_TARGET=1G to avoid sorting on TEMP tablespace.
    Frequently sorting happens on your DB and it supposed to shrink.
    You can also think of allocating other users to an specific TEMP tablespace but you have to identify which users it is.

  • Reporting Database growing rapidly

    Hello,
    Is it normal for the reporting database in SSRS to grow so rapidly? I created a new database 2 days ago, and already it has gone from 300 megabytes the first day to 3gb today. Usually, in a matter of 4-5 months, it grows to 30+ gb.
    Is it normal for it to do this? Once it get's too large it starts to slow the nightly refresh of content down and causes it to take much longer. Also, it seems that when it gets large like that, there are noticeable bottlenecks on the SQL box.
    If this is normal, is the solution just to create a new reporting database once in a while? Shrink it? What? I looked online and didn't see much info addressing this topic.

    It all depends on the number of transactions is carried over the database. If space is going to be constraint
    then take a log backup and shrink the log file.
    Refer the below article
    http://technet.microsoft.com/en-us/library/ms178037(v=sql.105).aspx
    -Prashanth

  • HELP ME PLEASE !!! dynamic pdf with table grows each time it's saved and reopened??? HELP PLEASE !

    Hi, I hope someone can help me. I created a form (dynamic pdf) with Livecycle ES 8.2.
    This document has a table in which rows are added when the user clicks on a button.
    The document in design stage takes up no more than 1/2 an A4. Here are my two problems;
    1. When the document is opened in Reader (9.3) it is all formatted correctly accept the one row, in it's default state (which can be added to by clicking button) is now three rows????
    2. Whether the two extra rows are deleted or filled in or whether more rows are added and filled in, if the document is saved and opened again with reader it has grown to a full page (of empty default rows). If saved again, it grows to 4 pages and so on.
    Can somebody please help me. I can supply a copy of my file if necessary.
    I don't know if this makes a difference, but the document is protected with a password to open in Livecycle and it also has user rights assigned for the user to be able to save a copy on their local machine (not just allowed to fill out and print).
    My email is [email protected]
    Would appreciate any help that can be offered. My document is ready (accept for this issue) for me to use in my job.
    Regards
    Bradd

    Bradd,
    Please forward the form and I can take a look. If you want to forward a version of the form that is not password protected or send the password in a separate email, that is up to you.
    [email protected]
    Steve

  • Table growing space.

    Hi GURU
    We are having a issue in the Production system. Table u201C/BIC/B0000404000u201D is growing very fast .
    In 1 month the table size grow upto 15 GB. Normally it should be less then 1 GB.
    To reduce the size we have delete the data. How can we see why the size of the data got increase.
    Let me know if you have any issue .
    regards
    Vikash

    Hi Vikash,
    Please check the frequecy of data upload & number of records .In last month ,there must increase in No. of records. If it is full Upload & scheduled daily then PSA table size increases very fast. For daily schedule upload  , PSA data is required after upload , it should be weekly.
    Hope , it will help.
    Have a nice day,
    Anand mehrotra.

  • Pagination using table growing property and multi-select table issues

    Hi,
    We're using the growing property on a table, thus the pagination is handled by the control it self.
    However, if we want to update some item in the table, in order to get those details reflected, we're refreshing the model, which is performance intensive.
    Is there any way we can update the UI only without creating any UI inconsistencies?
    Another question is that, is there any way to disbale the checkbox on the table items, based on some property from the backend. we tried to use editable property, but it hides the entire row.
    We need to disable the checkbox on the rows for particular items?
    Also, I need to know any resources on the mobile library where I can find the CSS related documentaion.
    Like we need to create a icon + text structure, which controls should be ideal to use? I have used
    <HBox><Icon src="abc"/><Text text="abc"/></Hbox>, but it creates alignment issues. Any ideas here?
    Thanks!
    Aamir

    855354 wrote:
    We are implementing pagination in our application and comparing the scrollable result set approach with using ROWNUM provided by oracle.The rownum approach scales better.
    Does this literrally mean that Oracle stores all the records in client-side memory cache? Well if it is scrollable it has to store all the rows somewhere, that is the disadvantage.
    Can we use fetchSize attribute or any other work around to limit the number of records in client-side memory?No. If you want that behavior that is how the rownum approach works.
    In the above case, when MAX_ROW_TO_FETCH is a large number (say 50000), then oracle will have to create a temporary table in memory with all the 50000 records and then will fetch from that table required records as per MIN_ROW_TO_FETCH.No, that is not how it works, where did you read that?
    In this case, reading rest of the records and storing in temporary in memory table will impact performance. Is my understanding correct or i am missing something here?Your understanding is not correct. The rownum approach does not work the way you think and behaves more like the way you want the scrollable result set to work.

  • DSVASRESULTSGEN/EWA table grow?

    Dear Expert,
    I noticed a consistently growth of segment DSVASRESULTSGEN in our Solution Manager system. It has been consistently growing about >1.0GB every month.
    As I understand, the DSVAS* tables are related to Service Session which might be entries generated by EWA sessions. Maybe this is related to EWA reports. Can we or how can I do housekeeping on this, to free up some of the database space?
    It will grow a lot when there is new EWA report setup.
    Do you have same experience, please share & guide me.
    thank you
    kelly

    Hi Lay
    SAP EarlyWatch Alerts and Service Level Reports can be stored on a separate file server, and then the session
    data can be deleted with the report RDSMOPREDUCEDATA
    you also might want to check #546685
    Nesimi
    Edited by: Nesimi Buelbuel on Sep 22, 2009 9:50 AM

Maybe you are looking for