Data Dictionary query takes too much time.

Hello,
I am using ORACLE DATABASE 11g.
The below query is taking too much time to execute and give the output. As i have tried a few Oracle sql hints but it dint worked out.
SELECT
distinct B.TABLE_NAME, 'Y'
FROM USER_IND_PARTITIONS A, USER_INDEXES B, USER_IND_SUBPARTITIONS C
WHERE A.INDEX_NAME = B.INDEX_NAME
   AND A.PARTITION_NAME = C.PARTITION_NAME
   AND C.STATUS = 'UNUSABLE'
    OR A.STATUS = 'UNUSABLE'
    OR B.STATUS = 'INVALID';Please guide me what to do ? to run this query in a fast pace mode ...
thanks in advance ..

Your query is incorrect. It will return ALL tables if A.STATUS = 'UNUSABLE' or B.STATUS = 'INVALID'. Most likely you meant:
SELECT
distinct B.TABLE_NAME, 'Y'
FROM USER_IND_PARTITIONS A, USER_INDEXES B, USER_IND_SUBPARTITIONS C
WHERE A.INDEX_NAME = B.INDEX_NAME
   AND A.PARTITION_NAME = C.PARTITION_NAME
   AND (C.STATUS = 'UNUSABLE'
    OR A.STATUS = 'UNUSABLE'
    OR B.STATUS = 'INVALID');But the above will return subpartitioned tables with invalid/unusable indexes. It will not return non-subpartitioned partitioned tables with invalid/unusable indexes/index partitions same as non-partitioned tables with invalid/unusable indexes. If you want to get any table with invalid/unusable indexes you need to outer join which will hurt performance even more. I suggest you use UNION:
SELECT DISTINCT TABLE_NAME,
                 'Y'
FROM (
          SELECT INDEX_NAME,'Y' FROM USER_INDEXES WHERE STATUS = 'INVALID'
         UNION ALL
          SELECT INDEX_NAME,'Y' FROM USER_IND_PARTITIONS WHERE STATUS = 'UNUSABLE'
         UNION ALL
          SELECT INDEX_NAME,'Y' FROM USER_IND_SUBPARTITIONS WHERE STATUS = 'UNUSABLE'
        ) A,
        USER_INDEXES B
WHERE A.INDEX_NAME = B.INDEX_NAME
/SY.

Similar Messages

Parsing the query takes too much time.

Hello.
I hitting the bug in в Oracle XE (parsing some query takes too much time).
A similar bug was previously found in the commercial release and was successfully fixed (SR Number 3-3301916511).
Please, raise a bug for Oracle XE.
Steps to reproduce the issue:
1. Extract files from testcase_dump.zip and testcase_sql.zip
2. Under username SYSTEM execute script schema.sql
3. Import data from file TESTCASE14.DMP
4. Under username SYSTEM execute script testcase14.sql
SQL text can be downloaded from http://files.mail.ru/DJTTE3
Datapump dump of testcase can be downloaded from http://files.mail.ru/EC1J36
Regards,
Viacheslav.

Bug number? Version fix applies to?
Relevant Note that describes the problem and points out bug/patch availability?
With a little luck some PSEs might be "backported", since 11g XE is not base release e.g. 11.2.0.1.

SELECT query takes too much time! Y?

Plz find my SELECT query below:
select w~mandt
wvbeln wposnr wmeins wmatnr wwerks wnetwr
wkwmeng wvrkme wmatwa wcharg w~pstyv
wposar wprodh wgrkor wantlf wkztlf wlprio
wvstel wroute wumvkz wumvkn wabgru wuntto
wawahr werdat werzet wfixmg wprctr wvpmat
wvpwrk wmvgr1 wmvgr2 wmvgr3 wmvgr4 wmvgr5
wbedae wcuobj w~mtvfp
xetenr xwmeng xbmeng xettyp xwepos xabart
x~edatu
xtddat xmbdat xlddat xwadat xabruf xetart
x~ezeit
into table t_vbap
from vbap as w
inner join vbep as x on xvbeln = wvbeln and
xposnr = wposnr and
xmandt = wmandt
where
( ( werdat > pre_dat ) and ( werdat <= w_date ) ) and
( ( ( erdat > pre_dat and erdat < p_syndt ) or
( erdat = p_syndt and erzet <= p_syntm ) ) ) and
w~matnr in s_matnr and
w~pstyv in s_itmcat and
w~lfrel in s_lfrel and
w~abgru = ' ' and
w~kwmeng > 0 and
w~mtvfp in w_mtvfp and
x~ettyp in w_ettyp and
x~bdart in s_req_tp and
x~plart in s_pln_tp and
x~etart in s_etart and
x~abart in s_abart and
( ( xlifsp in s_lifsp ) or ( xlifsp = ' ' ) ).
The problem: It takes too much time while executing this statement.
Could anybody change this statement and help me out to reduce the DB Access time?
Thx

Ways of Performance Tuning
1.     Selection Criteria
2.     Select Statements
     Select Queries
     SQL Interface
     Aggregate Functions
     For all Entries
Select Over more than one internal table
Selection Criteria
1.     Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2.     Select with selection list.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
         SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
              SBOOK_WA-CONNID = '0400'.
Select Statements   Select Queries
1.     Avoid nested selects
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
      WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
    FROM EKKO AS P INNER JOIN EKAN AS F
      ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
2.     Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
         SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
              SBOOK_WA-CONNID = '0400'.
3.     When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields. In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
4.     For testing existence, use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
    WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
5.     Use Select Single if all primary key fields are supplied in the Where condition .
If all primary key fields are supplied in the Where conditions you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements SQL Interface
1.     Use column updates instead of single-row updates
to update your database tables.
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
    SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
       SET SEATSOCC = SEATSOCC - 1.
2.     For all frequently used Select statements, try to use an index.
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
    AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
    AND CARRID = 'LH'
    AND CONNID = '0400'.
ENDSELECT.
3.     Using buffered tables improves the performance considerably.
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE     SPRSL = 'D'
        AND ARBGB = '00'
        AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE     SPRSL = 'D'
        AND ARBGB = '00'
        AND MSGNR = '999'.
Select Statements Aggregate Functions
     If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
            Maxno = 0.
            Select * from zflight where airln = LF and cntry = IN.
             Check zflight-fligh > maxno.
             Maxno = zflight-fligh.
            Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements For All Entries
     The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
     The plus
     Large amount of data
     Mixing processing and reading of data
     Fast internal reprocessing of data
     Fast
     The Minus
     Difficult to program/understand
     Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
     Check that data is present in the driver table
     Sorting the driver table
     Removing duplicates from the driver table
Consider the following piece of extract
          Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
                      Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
            Select * from zfligh appending table int_fligh
            For all entries in int_cntry
            Where cntry = int_cntry-cntry.
Endif.
Select Statements Select Over more than one Internal table
1.     Its better to use a views instead of nested Select statements.
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
        AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
    WHERE   DOMNAME    = DD01L_WA-DOMNAME
        AND AS4LOCAL   = 'A'
        AND AS4VERS    = DD01L_WA-AS4VERS
        AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
        AND DDLANGUAGE = SY-LANGU.
ENDSELECT
2.     To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
      WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
    FROM EKKO AS P INNER JOIN EKAN AS F
      ON PEBELN = FEBELN.
3.     Instead of using nested Select loops it is often better to use subqueries.
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
    AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
    INTO SFLIGHT_WA
    FOR ALL ENTRIES IN T_SPFLI
    WHERE SEATSOCC < F~SEATSMAX
      AND CARRID = T_SPFLI-CARRID
      AND CONNID = T_SPFLI-CONNID
      AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
    WHERE SEATSOCC < F~SEATSMAX
      AND EXISTS ( SELECT * FROM SPFLI
                     WHERE CARRID = F~CARRID
                       AND CONNID = F~CONNID
                       AND CITYFROM = 'FRANKFURT'
                       AND CITYTO = 'NEW YORK' )
      AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
1.     Table operations should be done using explicit work areas rather than via header lines.
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
2.     Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
3.     A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4.     A binary search using secondary index takes considerably less time.
5.     LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
6.     Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7.     Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
    <WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
    WA-FLAG = 'X'.
    MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
8.    If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
    ADD: WA1-VAL1 TO WA2-VAL1,
         WA1-VAL2 TO WA2-VAL2.
    MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
    INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
9.    "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
10.   DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
    DELETE ITAB.
ELSE.
    PREV_LINE = WA.
ENDIF.
ENDLOOP.
11.   "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12.   Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
13.   Specify the sort key as restrictively as possible to run the program faster.
SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables         contd
Hashed and Sorted tables
1.     For single read access hashed tables are more optimized as compared to sorted tables.
2.      For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP.

Azure Data Sync Log Take Too Much Time to Load

Hi,
I've found that the Azure Sync Log inside the Portal take too much time to load if my sync group was created long time ago. i.e. for those new sync group with only a few logs, it will take around 5 seconds for loading. However, I've many sync group created
more than 1 year, and it will take me up to 10 minutes for viewing the first page of the logs.
It seems the Portal will download ALL the logs to my browser even I just want to view the most recent logs (maybe I just want to view the last 10 records, but it will download the whole 5000 pages?)
It will be great if the Portal only fetch the data of the page I am currently viewing, instead of fetching all the logs.
Is there any ways to speed up the log loading time?
Michael Yung

Hello,
I suggest you post a feedback on
Azure SQL Data Sync feedback forum.
All of the feedback you share in the forum will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
Regards,
Fanny Liu
Fanny Liu
TechNet Community Support

Query takes too much time in fetching last records.

Hi,
I am using oracle 8.1 and trying to execute a SQL statement, it takes few minutes and display records.
When trying to fetch all the records, it is fast up to some level and takes much time to fetch last record.
Ex: If total records = 16336 , then it fetches records faster up to 16300 and takes app.500 sec to fetch last 36 records.
Could you kindly let me know the reason.
I have copied the explain plan below for your reference.Please let me know if anything is required.
SELECT STATEMENT, GOAL = RULE               4046     8     4048
NESTED LOOPS OUTER               4046     8     4048
NESTED LOOPS OUTER               4030     8     2952
   FILTER
    NESTED LOOPS OUTER
     NESTED LOOPS OUTER               4014     8     1728
      NESTED LOOPS               3998     8     936
       TABLE ACCESS BY INDEX ROWID     IFSAPP     CUSTOMER_ORDER_TAB     3966     8     440
        INDEX RANGE SCAN     IFSAPP     CUSTOMER_ORDER_1_IX     108     8
       TABLE ACCESS BY INDEX ROWID     IFSAPP     CUSTOMER_ORDER_LINE_TAB     4     30667     1901354
        INDEX RANGE SCAN     IFSAPP     CUSTOMER_ORDER_LINE_PK     3     30667
      TABLE ACCESS BY INDEX ROWID     IFSAPP     PWR_CONS_PARCEL_CONTENT_TAB     2     2000     198000
       INDEX RANGE SCAN     IFSAPP     PWR_CONS_PARCEL_CONTENT_1_IDX     1     2000
     TABLE ACCESS BY INDEX ROWID     IFSAPP     PWR_CONS_PARCEL_TAB     1     2000     222000
      INDEX UNIQUE SCAN     IFSAPP     PWR_CONS_PARCEL_PK          2000
   TABLE ACCESS BY INDEX ROWID     IFSAPP     CONSIGNMENT_PARCEL_TAB     1     2000     84000
    INDEX UNIQUE SCAN     IFSAPP     CONSIGNMENT_PARCEL_PK          2000
TABLE ACCESS BY INDEX ROWID     IFSAPP     PWR_OBJECT_CONNECTION_TAB     2     20     2740
   INDEX RANGE SCAN     IFSAPP     PWR_OBJECT_CONNECTION_IX1     1     20     Thanks.

We are using PL/SQL Developer tool. The time what we have mentioned in the post is approximated time.
Apologies for not mentioning these details in previous thread.Let it be approximate time but how did you arrive at that time? When a query fetches records how did you derived that one portion is fetched in x and the remaining in y time limit?
I would suggest this could be some issue with PL/SQL Developer (Never used this tool by myself) But for performance testing i would suggest you to use SQL Plus. Thats the best tool to test performance.

Insert query takes too much time

I have two select clauses as follows:
"select * from employee" This returns me 6000 rows.
& I have next clause as
"select * from employee where userid in(1,2,3,....,3000)"
This returns me 3000 rows.
Now i have to insert the result of above queries into same extended list view of Visual Basic. But the insert for first query takes 11 seconds while second takes 34 sec. We have evaluated this that this time is for insert query & not for select query.
I want to know that even if the Ist query returns 6000 rows it takes lesser time than the second which is
inserting 3000 rows.
We are using Oracle 8.1.7
Thanks in advance

The first query can do a straight dump of the table. The second select has to compare every userid to a hardcoded list of 3000 numbers. This will take quite a bit longer. Try rewriting it to
select * from employee where userid between 1 and 3000
It will run much faster then the other query.

Batch Query takes too much time

Hi All,
A query as simple as
select * from ibt1 where batchnum = 'AAA'
takes around 180 seconds to give results. if I replace batchnum condition with itemcode or anything other than batchnum, the same query returns results in some 5 seconds. the IBT1 table has nearly 3 lac rows. Consequently, a little complex query involving batchnm conditions gives 'query execution time out' error.
what could be the reason? any resolution?
Thanks,
Binita

Hello Binita,
You need some database tunning....
The IBT1 table has complex index on ItemCode, BatchNum, LineNum, WhsCode, and has no index on bacthnumber. But it has statistics, and statistics are useful for running queries ( see [ms technet here|http://technet.microsoft.com/hu-hu/library/cc966419(en-us).aspx]). Also there is a note about performance tunning databases 783183 .
There is 2 ways to "speed up" your query: indexes and statistics
Statistics
See the statistics of IBT1 table:
exec SP_HELPSTATS 'IBT1','ALL'
the result set you see : the statistics name ([IBT1_PRIMARY] and some statistics created by the system name likes WASys_XXXX. For Batchnum, you can execute the following statement:
DBCC SHOW_STATISTICS ('IBT1',_WA_Sys_00000002_4EE969DE)
--where _WA_Sys_00000002_4EE969DE is the name of the statistics of batchnum
Check the resultset. If the "updated", "rows","row sampled" columns. If necessary, you can update the statistics by:
-- update statistics on whole database
EXEC SP_UPDATESTATS
-- update all statistics of IBT1 table
UPDATE STATISTICS IBT1 WITH FULLSCAN
-- update a specific statistics of IBT1 table
UPDATE STATISTICS IBT1(_WA_Sys_00000002_4EE969DE) WITH FULLSCAN
Index defragmentation/reindex
If the index not contiguous, the seeking inside several fragmented files takes more time.
Execute your query in Management Studio Query analizer, and trun on Excution plans (CTRLL or CTRLM). This shows the compute cost of the query.
select * from ibt1 where batchnum = 'AAA'
result will be [IBT1_PRIMARY] index scan. You can check the fragmentation of the primary index of IBT1 table:
DBCC SHOWCONTIG ('IBT1') WITH FAST, TABLERESULTS, ALL_INDEXES, NO_INFOMSGS
In the resultset the column ScanDensity shows the fragmentation percent, This value is 100 if everything is contiguous; if this value is less than 100, some fragmentation exists.
Reindex can be done by the following statement:
DBCC DBREINDEX ('IBT1','IBT1_PRIMARY',100) WITH NO_INFOMSGS
Take care: all statements should NOT be execute during business hours.
This may helps you.
Regards,
J.

Query taking too much time with dates??

hello folks,
I am trying pull some data using the date condition and for somereason its taking too much time to return the data
and trunc(al.activity_date) = TRUNC (SYSDATE, 'DD') - 1 --If i use this its takes too much time
and al.activity_date >= to_date('20101123 000000', 'YYYYMMDD HH24MISS')
and al.activity_date <= to_date('20101123 235959', 'YYYYMMDD HH24MISS') -- If i use this it returns the data in a second. why is that?
How do i get the previous day without using the hardcoded to_date('20101123 000000', 'YYYYMMDD HH24MISS'), if i need to retrieve it faster??

Presumably you've got an index on activity_date.
If you apply a function like TRUNC to activity_date, you can no longer use the index.
Post execution plans to verify.
and al.activity_date >= TRUNC (SYSDATE, 'DD') - 1
and al.activity_date < TRUNC (SYSDATE, 'DD')

Bootcamp: WinXP: Network initialization takes too much time

Hey
I've set up a BootCamp partition on my Macbook 6,1: Windows XP Professional 32-bit SP3 (up-to-date).
Its a fresh installation, with latest BootCamp drivers.
From start on, the network-initialization takes too much time:
- Windows boots up
- Enter password
- Desktop appear
- after 2-3 minutes, the network symbols appear in the taskbar.
If I open the System Control panel and want to enter the networking-devices it loads until network is really initiated.
I also can't browse to any web-site (through IE).
So, it seems that something blocks or prevent the networking from fast start-up.
I've tried to disable WLAN, same problem
If I disconnect all connections (no LAN-cable, no WLAN configured) its still the same problem.
Does anybody have a similar issue?

You can read: I have installed BootCamp (Lions one said no, but I have an MacBook 6,1 - Yep, this one was shipped with Snow Leopard, so I have the "old" BootCamp drivers with XP-drivers on my Install-disc.).
The BootCamp drivers from the Mac OSX 10.6 CD are installed and updated through Apple-Update.
So, WinXP should be supported?

The queries takes too much time

Hi,
I want to compare time of queries between Spatial and PostGIS, but Spatial take too much time. I created spatial indexes in both databases so I have no idea where can be the problem :-(. I'm actually student and I try this for my essay, but I start with Oracle by myself so I'll appreciate some help.
I have table with cca 7000 polygons and I want to create new table like dissolve these polygons by attribute katuze.
Query in Spatial takes 8506 s :
CREATE TABLE dp_diss_p AS
SELECT KATUZE_KOD, SDO_AGGR_UNION(
MDSYS.SDOAGGRTYPE(a.geom, 0.005))GEOM
FROM dp_plochy a GROUP BY a.KATUZE_KOD;
Query in PostGIS takes 10.149 s :
CREATE TABLE plochy_diss AS
SELECT st_union(geom) AS geom
FROM plochy
GROUP BY katuze_kod;
I really don't know what to do, please give somebody me some advice :-(. Please excuse my English.
Thx Eva

I tryed use the sdo_aggr_set_union like this:
CREATE OR REPLACE FUNCTION get_geom_set (table_name VARCHAR2,
column_name VARCHAR2,
predicate VARCHAR2 := NULL)
RETURN SDO_GEOMETRY_ARRAY DETERMINISTIC AS
type cursor_type is REF CURSOR;
query_crs cursor_type ;
g SDO_GEOMETRY;
GeometryArr SDO_GEOMETRY_ARRAY;
where_clause VARCHAR2(2000);
BEGIN
IF predicate IS NULL
THEN
where_clause := NULL;
ELSE
where_clause := ' WHERE ';
END IF;
GeometryArr := SDO_GEOMETRY_ARRAY();
OPEN query_crs FOR ' SELECT ' || column_name ||
' FROM ' || table_name ||
where_clause || predicate;
LOOP
FETCH query_crs into g;
EXIT when query_crs%NOTFOUND ;
GeometryArr.extend;
GeometryArr(GeometryArr.count) := g;
END LOOP;
RETURN GeometryArr;
END;
CREATE TABLE dp_diss_p AS
SELECT KATUZE_KOD, sdo_aggr_set_union (get_geom_set ('dp_plochy', 'geom','CTVUK_KOD <>''1'''), .0005 ) geom
FROM dp_plochy a GROUP BY a.KATUZE_KOD;
It takes 21.721 s, but it return type of collection and I can't export it to *.shp because Georaptor export it like 'unknown' . Has anybody idea what can I do with it to export it like polygon?
Eva

PDPageDrawContentsToWindowEx takes too much time

We are using an Acrobat plugin that renders the PDF file to a bitmap in memory.
We are using Acrobat Professional X. But same problems also appear on Acrobat 9.
We have received several problematic PDF files from our customers that is causing the call that renders the image -
PDPageDrawContentsToWindowEx() to take unreasonably long time.
My target resolutions is 600 dpi but I couldn't wait for the call to return, after more than 6 minutes I kill the process.
The same PDFs render in Acrobat with slight delay (flickering and repainting) but in reasonable time.
I have written for this problem on previous occasions (Aug 5 2010). Since then further problematic samples
show that is linked somehow with transparency being present, but not on all PDFs with transparency.
We have a fast computer so the problem is somewhere in the PDF analysis.
Trying to optimize the file didn't help.
Checking with Preflight for PDF syntax issues also didn't find anything.

I'll have to check the headers, but I KNOW that we exposed it to plugins in A9 – it was necessary since we pulled the DrawToWindow call on the Mac (carbon vs. cocoa).
What you are asking the SDK to do is going to be painful on large complex images. Drawing into an HDC/Window adds SIGNIFICANT overhead to our rendering process, since we have to do all the work in our own "bit buffer" and then copy that buffer into the OS's provided HDC. OUCH! This is why DrawToMemory is better.
Additionally, if you have files with complex transparency AND you want OverprintPreview, that's also going to be VERY complex rendering pipeline – made WORSE by the need to end up in an HDC. Forgetting separations for the moment, consider that we have to convert everything to CMYK (since you can only compute OP in CMYK), blend colors, then convert all of that to RGB. And that's assuming SIMPLE transparency. If you have multiple blending groups, soft masks, etc. then you just raised the bar even more!
How long does it take Acrobat to open up the PDF and render it completely to screen? For separations, how long does it take to do a "Flatten Transparency" operation?
UpdateRect won't help because of the OP and then transparency flattening
From: Adobe Forums <[email protected]<mailto:[email protected]>>
Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Date: Mon, 5 Dec 2011 06:45:46 -0800
To: Leonard Rosenthol <[email protected]<mailto:[email protected]>>
Subject: PDPageDrawContentsToWindowEx takes too much time
Re: PDPageDrawContentsToWindowEx takes too much time
created by Nikolay Tasev<http://forums.adobe.com/people/Nikolay+Tasev> in Acrobat SDK - View the full discussion<http://forums.adobe.com/message/4064198#4064198

Finishing Backup takes too much time.

Finishing backup takes too much time in my system , sometimes 30 minutes even 1 hour! and sometimes right after finishing backup(before the icon in the menu bar stops) it starts to take another backup( and usually 10MB or something small !) or the estimation is wrong .
Sometimes I see my system that is taking backups hours and hours(just with small stops!)
and the speed rate I of data transfer is reduced, while I set it to be on maximum speed in Time Capsule.

And the log with Time-stamps from Console
4/6/09 2:31:24 PM /System/Library/CoreServices/backupd[2141] Starting standard backup
4/6/09 2:31:34 PM /System/Library/CoreServices/backupd[2141] Mounted network destination using URL: afp://[email protected]/Sina's%20Time%20Capsule
4/6/09 2:31:34 PM /System/Library/CoreServices/backupd[2141] Backup destination mounted at path: /Volumes/Sina's Time Capsule
4/6/09 2:31:39 PM /System/Library/CoreServices/backupd[2141] Disk image /Volumes/Sina's Time Capsule/Sina’s MacBook_0017f2347181.sparsebundle mounted at: /Volumes/Backup of Sina’s MacBook
4/6/09 2:31:39 PM /System/Library/CoreServices/backupd[2141] Backing up to: /Volumes/Backup of Sina’s MacBook/Backups.backupdb
4/6/09 2:39:45 PM /System/Library/CoreServices/backupd[2141] No pre-backup thinning needed: 862.6 MB requested (including padding), 205.56 GB available
4/6/09 2:46:52 PM /System/Library/CoreServices/backupd[2141] Bulk setting Spotlight attributes failed.
4/6/09 2:48:07 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 2:48:07 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 2:48:07 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 2:50:06 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 2:50:06 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 2:57:21 PM /System/Library/CoreServices/backupd[2141] Bulk setting Spotlight attributes failed.
4/6/09 3:03:57 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 3:03:58 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 3:03:58 PM /System/Library/CoreServices/backupd[2141] Unable to rebuild path cache for source item. Partial source path:
4/6/09 3:12:55 PM /System/Library/CoreServices/backupd[2141] Copied 29426 files (162.6 MB) from volume Macintosh Disk.
4/6/09 3:17:36 PM /System/Library/CoreServices/backupd[2141] No pre-backup thinning needed: 678.9 MB requested (including padding), 205.56 GB available
4/6/09 3:37:18 PM /System/Library/CoreServices/backupd[2141] Bulk setting Spotlight attributes failed.
4/6/09 3:37:57 PM /System/Library/CoreServices/backupd[2141] Copied 2362 files (100.3 MB) from volume Macintosh Disk.
4/6/09 3:42:00 PM /System/Library/CoreServices/backupd[2141] Starting post-backup thinning

Language import takes too much time in ECC EHP4 system

Hi All,
We are trying to import the Languages in to ECC EHP4 system ...But each Language takes almost 48 hours to get imported.
and even the language supplementation takes too much time ...
Please help in tuning the memory parameter if required ...and the Data Base is DB2

Hi,
So what is your system details ?
OS ?
Have you just installed the system ?
Just upgraded to EHP4 ?
Any trace files ?
what is the system load.....
Mark

White MacBook takes too much time to boot up

Hi there.
I got the topcase(keyboard) of my MacBook repaired. (White MacBook 2006) and after that it takes nearly 7 up to 10 seconds after pressing the power button that I first see apple logo and it boots up.
I'm not sure but seems like that detecting the hardwares take too much time .
any solution?
PS: I'm running Snow Leopard(10.6.2)

macbig wrote:
OK, 32 seconds is not good. I don't think it has anything to do with a keyboard repair. You need to try a little maintenance: Reset Pram - http://docs.info.apple.com/article.html?artnum=2238
Repair Permissions - http://support.apple.com/kb/HT1452
Run Disk Utility >applications>utilities>disk utilities>verify disk
How much free space do you have on your HD: Right click on HD icon and select "get info" in the drop down menu (if you don't have right click capabilities, highlight your HD icon, go file in the Apple menu, and select "get info" in the drop down menu. Let us know your results.
Yes PRAM was the the problem, I've already tried it from this thread http://discussions.apple.com/thread.jspa?threadID=2303507&tstart=0
by the way thank you .

Itunes takes too much time to open and don´t recogneize my iphone

itunes takes too much time to open and don´t recogneize my iphone
I´ve alredy unistall and re install and didn´t work

5-10 minutes is normal for me when opening iTunes. But then my library is stored on network drive which slows everything down.
There has been many posts about problems with RAID and iTunes. Don't know if any of those relate.

Data Dictionary query takes too much time.

Similar Messages

Maybe you are looking for