Purge Stats History taking too long

Hi,
I am doing a purge of stats history on my database and it is taking ages for what I believe should be a small data set
I have checked the stats history retention using
select dbms_stats.get_stats_history_availability from dual;
26/11/2010 22:10:42.668499000 +00:00
select sysdate-500
from dual;
12/12/2010 10:52:09
exec dbms_stats.purge_stats(sysdate-500);
The above purge has been running for over an hour ( and is still going ! ). This is on a test system with no real other activity going on within it.
Q1. Why is the above purge taking so long on what should be a relatively small data set ?
any help greatly appreciated,
Jim

So sorry,
from doc.
PURGE_STATS Procedure
This procedure purges old versions of statistics saved in the dictionary. To run this procedure, you must have the SYSDBA or both ANALYZE ANY DICTIONARY and ANALYZE ANY system privilege.
Syntax
DBMS_STATS.PURGE_STATS(
before_timestamp TIMESTAMP WITH TIME ZONE);
Delete all infor before 1,5 years. How many time you have beyond this date ??? the problem is the UNDO, purge using a batch process, delete from days to days, or using weeks.
HTH
Antonio NAVARRO

Similar Messages

SQL Update statement taking too long..

Hi All,
I have a simple update statement that goes through a table of 95000 rows that is taking too long to update; here are the details:
Oracle Version: 11.2.0.1 64bit
OS: Windows 2008 64bit
desc temp_person;
Name                                                                                Null?    Type
PERSON_ID                                                                           NOT NULL NUMBER(10)
DISTRICT_ID                                                                     NOT NULL NUMBER(10)
FIRST_NAME                                                                                   VARCHAR2(60)
MIDDLE_NAME                                                                                  VARCHAR2(60)
LAST_NAME                                                                                    VARCHAR2(60)
BIRTH_DATE                                                                                   DATE
SIN                                                                                          VARCHAR2(11)
PARTY_ID                                                                                     NUMBER(10)
ACTIVE_STATUS                                                                       NOT NULL VARCHAR2(1)
TAXABLE_FLAG                                                                                 VARCHAR2(1)
CPP_EXEMPT                                                                                   VARCHAR2(1)
EVENT_ID                                                                            NOT NULL NUMBER(10)
USER_INFO_ID                                                                                 NUMBER(10)
TIMESTAMP                                                                           NOT NULL DATE
CREATE INDEX tmp_rs_PERSON_ED ON temp_person (PERSON_ID,DISTRICT_ID) TABLESPACE D_INDEX;
Index created.
ANALYZE INDEX tmp_PERSON_ED COMPUTE STATISTICS;
Index analyzed.
explain plan for update temp_person
2 set first_name = (select trim(f_name)
3                    from ext_names_csv
4                               where temp_person.PERSON_ID=ext_names_csv.p_id
5                               and   temp_person.DISTRICT_ID=ext_names_csv.ed_id);
Explained.
@?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3786226716
| Id | Operation                   | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT            |                | 82095 | 4649K| 2052K (4)| 06:50:31 |
|   1 | UPDATE                     | TEMP_PERSON    |       |       |            |          |
|   2 |   TABLE ACCESS FULL         | TEMP_PERSON    | 82095 | 4649K|   191   (1)| 00:00:03 |
|* 3 |   EXTERNAL TABLE ACCESS FULL| EXT_NAMES_CSV |     1 |   178 |    24   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - filter("EXT_NAMES_CSV"."P_ID"=:B1 AND "EXT_NAMES_CSV"."ED_ID"=:B2)
Note
   - dynamic sampling used for this statement (level=2)
19 rows selected.By the looks of it the update is going to take 6 hrs!!!
ext_names_csv is an external table that have the same number of rows as the PERSON table.
ROHO@rohof> desc ext_names_csv
Name                                                                                Null?    Type
P_ID                                                                                         NUMBER
ED_ID                                                                                        NUMBER
F_NAME                                                                                       VARCHAR2(300)
L_NAME                                                                                       VARCHAR2(300)Anyone can help diagnose this please.
Thanks
Edited by: rsar001 on Feb 11, 2011 9:10 PM

Thank you all for the great ideas, you have been extremely helpful. Here is what we did and were able to resolve the query.
We started with Etbin's idea to create a table from the ext table so that we can index and reference easier than an external table, so we did the following:
SQL> create table ext_person as select P_ID,ED_ID,trim(F_NAME) fst_name,trim(L_NAME) lst_name from EXT_NAMES_CSV;
Table created.
SQL> desc ext_person
Name                                                                                Null?    Type
P_ID                                                                                         NUMBER
ED_ID                                                                                        NUMBER
FST_NAME                                                                                     VARCHAR2(300)
LST_NAME                                                                                     VARCHAR2(300)
SQL> select count(*) from ext_person;
COUNT(*)
     93383
SQL> CREATE INDEX EXT_PERSON_ED ON ext_person (P_ID,ED_ID) TABLESPACE D_INDEX;
Index created.
SQL> exec dbms_stats.gather_index_stats(ownname=>'APPD', indname=>'EXT_PERSON_ED',partname=> NULL , estimate_percent=> 30 );
PL/SQL procedure successfully completed.We had a look at the plan with the original SQL query that we had:
SQL> explain plan for update temp_person
2 set first_name = (select fst_name
3                    from ext_person
4                               where temp_person.PERSON_ID=ext_person.p_id
5                               and   temp_person.DISTRICT_ID=ext_person.ed_id);
Explained.
SQL> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 1236196514
| Id | Operation                    | Name           | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT             |                | 93383 | 1550K|   186K (50)| 00:37:24 |
|   1 | UPDATE                      | TEMP_PERSON    |       |       |            |          |
|   2 |   TABLE ACCESS FULL          | TEMP_PERSON    | 93383 | 1550K|   191   (1)| 00:00:03 |
|   3 |   TABLE ACCESS BY INDEX ROWID| EXTT_PERSON    |     9 | 1602 |     1   (0)| 00:00:01 |
|* 4 |    INDEX RANGE SCAN          | EXT_PERSON_ED |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - access("EXT_PERSON"."P_ID"=:B1 AND "RS_PERSON"."ED_ID"=:B2)
Note
   - dynamic sampling used for this statement (level=2)
20 rows selected.As you can see the time has dropped to 37min (from 6 hrs). Then we decided to change the SQL query and use donisback's suggestion (using MERGE); we explained the plan for teh new query and here is the results:
SQL> explain plan for MERGE INTO temp_person t
2 USING (SELECT fst_name ,p_id,ed_id
3 FROM ext_person) ext
4 ON (ext.p_id=t.person_id AND ext.ed_id=t.district_id)
5 WHEN MATCHED THEN
6 UPDATE set t.first_name=ext.fst_name;
Explained.
SQL> @?/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2192307910
| Id | Operation            | Name         | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | MERGE STATEMENT      |              | 92307 |    14M|       | 1417   (1)| 00:00:17 |
|   1 | MERGE               | TEMP_PERSON |       |       |       |            |          |
|   2 |   VIEW               |              |       |       |       |            |          |
|* 3 |    HASH JOIN         |              | 92307 |    20M| 6384K| 1417   (1)| 00:00:17 |
|   4 |     TABLE ACCESS FULL| TEMP_PERSON | 93383 | 5289K|       |   192   (2)| 00:00:03 |
|   5 |     TABLE ACCESS FULL| EXT_PERSON   | 92307 |    15M|       |    85   (2)| 00:00:02 |
Predicate Information (identified by operation id):
   3 - access("P_ID"="T"."PERSON_ID" AND "ED_ID"="T"."DISTRICT_ID")
Note
   - dynamic sampling used for this statement (level=2)
21 rows selected.As you can see, the update now takes 00:00:17 to run (need to say more?) :)
Thank you all for your ideas that helped us get to the solution.
Much appreciated.
Thanks

Update statement taking too long to execute

Hi All,
I'm trying to run this update statement. But its taking too long to execute.
    UPDATE ops_forecast_extract b SET position_id = (SELECT a.row_id
        FROM s_postn a
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME)))
        WHERE position_level = 7
        AND b.am_id IS NULL;
        SELECT COUNT(*) FROM S_POSTN;
        214665
        SELECT COUNT(*) FROM ops_forecast_extract;
        49366
SELECT count(*)
        FROM s_postn a, ops_forecast_extract b
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME));
575What could be the reason for update statement to execute so long?
Thanks

polasa wrote:
Hi All,
I'm trying to run this update statement. But its taking too long to execute.
What could be the reason for update statement to execute so long?You haven't said what "too long" means, but a simple reason could be that the scalar subquery on "s_postn" is using a full table scan for each execution. Potentially this subquery gets executed for each row of the "ops_forecast_extract" table that satisfies your filter predicates. "Potentially" because of the cunning "filter/subquery optimization" of the Oracle runtime engine that attempts to cache the results of already executed instances of the subquery. Since the in-memory hash table that holds these cached results is of limited size, the optimization algorithm depends on the sort order of the data and could suffer from hash collisions it's unpredictable how well this optimization works in your particular case.
You might want to check the execution plan, it should tell you at least how Oracle is going to execute the scalar subquery (it doesn't tell you anything about this "filter/subquery optimization" feature).
Generic instructions how to generate a useful explain plan output and how to post it here follow:
Could you please post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your statement. Please use the {noformat}[{noformat}code{noformat}]{noformat} tag before and {noformat}[{noformat}/code{noformat}]{noformat} tag after or the {noformat}{{noformat}code{noformat}}{noformat} tag before and after to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Note that the package DBMS_XPLAN.DISPLAY is only available from 9i on.
In 9i and above, if the "Predicate Information" section is missing from the DBMS_XPLAN.DISPLAY output but you get instead the message "Plan table is old version" then you need to re-create your plan table using the server side script "$ORACLE_HOME/rdbms/admin/utlxplan.sql".
In previous versions you could run the following in SQL*Plus (on the server) instead:
@?/rdbms/admin/utlxplsA different approach in SQL*Plus:
SET AUTOTRACE ON EXPLAIN
<run your statement>;will also show the execution plan.
In order to get a better understanding where your statement spends the time you might want to turn on SQL trace as described here:
When your query takes too long ...
and post the "tkprof" output here, too.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

SQL Statement taking too long to get the data

Hi,
There are over 2500 records in a table and when retrieve all using ' SELECT * From Table' it is taking too long to get the data. ie .. 4.3 secs.
Is there any possible way to shorten the process time.
Thanks

Hi Patrick,
Here is the sql statement and table desc.
ID     Number
SN     Varchar2(12)
FN     Varchar2(30)
LN     Varchar2(30)
By     Varchar(255)
Dt     Date(7)
Add     Varchar2(50)
Add1     Varchar2(30)
Cty     Varchar2(30)
Stt     Varchar2(2)
Zip     Varchar2(12)
Ph     Varchar2(15)
Email     Varchar2(30)
ORgId     Number
Act     Varchar2(3)
select A."FN" || '' '' || A."LN" || '' ('' || A."SN" || '')'' "Name",
A."By", A."Dt",
A."Add" || ''
'' || A."Cty" || '', '' || A."Stt" || '' '' || A."Zip" "Location",
A."Ph", A."Email", A."ORgId", A."ID",
A."SN" "OSN", A."Act"
from "TBL_OPTRS" A where A."ID" <> 0 ';
I'm displaying all rows in a report.
if I use 'select * from TBL_OPTRS' , this also takes 4.3 to 4.6 secs.
Thanks.

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.

WebI Report is taking too long time to opening

Hi All,
When iam trying to open the WebI report in Infoview , it is taking long time to open and refresh,
Please suggest me a solution.
Thanks in advance..
Regards,
Mahesh

Hi,
As the issue you are facing is that the webi report is taking too long to open and refresh, I would recommend the below steps.
1. Check whether the webi report is set to "Refreh on Open" if yes probably you need to uncheck, save the report and open it again.
2. Try to run the same query in the backend database and see if it returns the data.
3. Try to run refresh the report for a smaller data selection.
4. make the report run on a specific webi server, and when refreshing have your BOBJ admin monitor that process to see if the process is going in a hung state, using High memory etc.
5. restart webi process and run again
Thanks,
aKs

When query is taking too long time

When query is taking too long time,Where and how to start tuning it?
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)
2.Parameter modification need to be done at system/session level
3.The query has to be tuned (using hints )
4.Gathering/deleting statistics
List out any other things that need to be taken into account?
Which approach must be followed and on what basis that approach must be considered?

When query is taking too long time,Where and how to start tuning it?explain plan will be good start . trace also
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)When Oracle executes an SQL statement, it is not constantly executing. Sometimes it has to wait for a specific event to happen befor it can proceed.
Read
http://www.adp-gmbh.ch/ora/tuning/event.html
2.Parameter modification need to be done at system/session levelDepend on parameter , define parameter , trace done on session level for example
3.The query has to be tuned (using hints )Could be help you but you must know how to use .
4.Gathering/deleting statisticsDo it in non working hours , it will impact on database performance , but its good
List out any other things that need to be taken into account?Which account ?
Which approach must be followed and on what basis that approach must be considered?you could use lot of tools , Trace , AWR

Query is taking too long to execute - contd

I am unable to post the entire explain plan in one post as it exceeds maximum length.
Please advise on how to post this.
Previous post Link : Link: Query is taking too long to execute
Regards,
Sreekanth Munagala.
Edited by: Sreekanth Munagala on Oct 27, 2009 8:31 AM
Edited by: Sreekanth Munagala on Oct 27, 2009 8:34 AM

Hi Tubby,
Today i executed only the first query in the view and it took almost 2.5 hrs.
Here is the explain plan for this query
SQL> SET SERVEROUTPUT ON
SQL> set linesize 200
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation                                        | Name                         | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                                 |                               |     1 |   766 | 2448 |
|   1 | TABLE ACCESS BY INDEX ROWID                     | PO_VENDORS                    |     1 |    13 |     3 |
|* 2 |   INDEX UNIQUE SCAN                              | PO_VENDORS_U1                 |     1 |       |     2 |
|   3 | TABLE ACCESS BY INDEX ROWID                     | PO_VENDORS                    |     1 |    29 |     3 |
|* 4 |   INDEX UNIQUE SCAN                              | PO_VENDORS_U1                 |     1 |       |     2 |
|   5 | VIEW                                            | POC_ASN_PICKUP_LOCATIONS_V    |     2 | 2426 |    17 |
|   6 |   UNION-ALL                                      |                               |       |       |       |
|   7 |    NESTED LOOPS                                  |                               |     1 |    85 |     4 |
|   8 |     NESTED LOOPS                                 |                               |     1 |    78 |     4 |
|* 9 |      TABLE ACCESS BY INDEX ROWID                 | PO_VENDOR_SITES_ALL           |     1 |    73 |     3 |
|* 10 |       INDEX UNIQUE SCAN                          | PO_VENDOR_SITES_U2            |     1 |       |     2 |
|* 11 |      INDEX UNIQUE SCAN                           | PO_VENDORS_U1                 |     1 |     5 |     1 |
|* 12 |     INDEX UNIQUE SCAN                            | FND_TERRITORIES_TL_U1         |     1 |     7 |       |
| 13 |    NESTED LOOPS                                  |                               |     1 |    91 |    13 |
| 14 |     NESTED LOOPS                                 |                               |     1 |    84 |    13 |
| 15 |      TABLE ACCESS BY INDEX ROWID                 | PO_VENDORS                    |     1 |    13 |     3 |
|* 16 |       INDEX UNIQUE SCAN                          | PO_VENDORS_U1                 |     1 |       |     2 |
PLAN_TABLE_OUTPUT
|* 17 |      TABLE ACCESS BY INDEX ROWID                 | FND_LOOKUP_VALUES             |     1 |    71 |    10 |
|* 18 |       INDEX RANGE SCAN                           | FND_LOOKUP_VALUES_U2          |    13 |       |     2 |
|* 19 |     INDEX UNIQUE SCAN                            | FND_TERRITORIES_TL_U1         |     1 |     7 |       |
|* 20 | COUNT STOPKEY                                   |                               |       |       |       |
| 21 |   TABLE ACCESS BY INDEX ROWID                    | MTL_SYSTEM_ITEMS_B            |     8 |   136 |    12 |
|* 22 |    INDEX RANGE SCAN                              | MTL_SYSTEM_ITEMS_B_U1         |     8 |       |     3 |
|* 23 | COUNT STOPKEY                                   |                               |       |       |       |
| 24 |   TABLE ACCESS BY INDEX ROWID                    | MTL_SYSTEM_ITEMS_B            |     8 |   288 |    12 |
|* 25 |    INDEX RANGE SCAN                              | MTL_SYSTEM_ITEMS_B_U1         |     8 |       |     3 |
| 26 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 27 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
| 28 | NESTED LOOPS                                    |                               |     1 |    40 |     5 |
| 29 |   TABLE ACCESS BY INDEX ROWID                    | HZ_CUST_ACCOUNTS              |     1 |    11 |     3 |
|* 30 |    INDEX UNIQUE SCAN                             | HZ_CUST_ACCOUNTS_U1           |     1 |       |     2 |
| 31 |   TABLE ACCESS BY INDEX ROWID                    | HZ_PARTIES                    |     1 |    29 |     2 |
|* 32 |    INDEX UNIQUE SCAN                             | HZ_PARTIES_U1                 |     1 |       |     1 |
| 33 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 34 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
| 35 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 36 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
|* 37 | COUNT STOPKEY                                   |                               |       |       |       |
PLAN_TABLE_OUTPUT
|* 38 |   TABLE ACCESS BY INDEX ROWID                    | ONTC_MTC_PROFORMA_HEADERS     |     1 |    21 |     3 |
|* 39 |    INDEX RANGE SCAN                              | ONTC_MTC_PROFORMA_HEADERS_U2 |     1 |       |     2 |
| 40 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 41 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
|* 42 | COUNT STOPKEY                                   |                               |       |       |       |
|* 43 |   TABLE ACCESS BY INDEX ROWID                    | ONTC_MTC_PROFORMA_HEADERS     |     1 |    21 |     3 |
|* 44 |    INDEX RANGE SCAN                              | ONTC_MTC_PROFORMA_HEADERS_U2 |     1 |       |     2 |
| 45 | SORT AGGREGATE                                  |                               |     1 |    39 |       |
| 46 |   NESTED LOOPS OUTER                             |                               |     2 |    78 | 1828 |
|* 47 |    TABLE ACCESS FULL                             | ONTC_MTC_PROFORMA_HEADERS     |     1 |    24 | 1825 |
| 48 |    TABLE ACCESS BY INDEX ROWID                   | ONTC_MTC_PROFORMA_LINES       |     5 |    75 |     3 |
|* 49 |     INDEX RANGE SCAN                             | ONTC_MTC_PROFORMA_LINES_PK    |    11 |       |     2 |
| 50 | NESTED LOOPS                                    |                               |     1 |   766 | 2448 |
| 51 |   NESTED LOOPS                                   |                               |     1 |   761 | 2447 |
| 52 |    NESTED LOOPS                                  |                               |     1 |   746 | 2445 |
| 53 |     NESTED LOOPS                                 |                               |     1 |   694 | 2443 |
| 54 |      NESTED LOOPS                                |                               |     1 |   682 | 2441 |
| 55 |       NESTED LOOPS                               |                               |     1 |   671 | 2439 |
| 56 |        NESTED LOOPS                              |                               |     1 |   612 | 2437 |
| 57 |         NESTED LOOPS                             |                               |     1 |   600 | 2435 |
| 58 |          NESTED LOOPS                            |                               |     1 |   575 | 2433 |
PLAN_TABLE_OUTPUT
| 59 |           NESTED LOOPS                           |                               |     1 |   552 | 2431 |
| 60 |            NESTED LOOPS                          |                               |     1 |   533 | 2429 |
| 61 |             NESTED LOOPS                         |                               |     1 |   524 | 2428 |
| 62 |              NESTED LOOPS                        |                               |     1 |   455 | 2427 |
| 63 |               NESTED LOOPS                       |                               |     1 |   429 | 2426 |
| 64 |                NESTED LOOPS                      |                               |     1 |   389 | 2424 |
| 65 |                 NESTED LOOPS                     |                               |     1 |   368 | 2422 |
| 66 |                  NESTED LOOPS                    |                               |     1 |   308 | 2421 |
| 67 |                   NESTED LOOPS                   |                               |     1 |   281 | 2419 |
| 68 |                    NESTED LOOPS                  |                               |     1 |   253 | 2418 |
| 69 |                     NESTED LOOPS                 |                               |     1 |   214 | 2416 |
| 70 |                      NESTED LOOPS                |                               |    39 | 7371 | 2338 |
|* 71 |                       TABLE ACCESS FULL          | RCV_SHIPMENT_HEADERS          |    39 | 5070 | 2221 |
|* 72 |                       TABLE ACCESS BY INDEX ROWID| RCV_SHIPMENT_LINES            |     1 |    59 |     3 |
|* 73 |                        INDEX RANGE SCAN          | RCV_SHIPMENT_LINES_U2         |     1 |       |     2 |
|* 74 |                      TABLE ACCESS BY INDEX ROWID | PO_LINES_ALL                  |     1 |    25 |     2 |
|* 75 |                       INDEX UNIQUE SCAN          | PO_LINES_U1                   |     1 |       |     1 |
|* 76 |                     TABLE ACCESS BY INDEX ROWID | PO_LINE_LOCATIONS_ALL         |     1 |    39 |     2 |
|* 77 |                      INDEX UNIQUE SCAN           | PO_LINE_LOCATIONS_U1          |     1 |       |     1 |
|* 78 |                    TABLE ACCESS BY INDEX ROWID   | PO_HEADERS_ALL                |     1 |    28 |     1 |
|* 79 |                     INDEX UNIQUE SCAN            | PO_HEADERS_U1                 |     1 |       |       |
PLAN_TABLE_OUTPUT
|* 80 |                   TABLE ACCESS BY INDEX ROWID    | OE_ORDER_LINES_ALL            |     1 |    27 |     2 |
|* 81 |                    INDEX UNIQUE SCAN             | OE_ORDER_LINES_U1             |     1 |       |     1 |
| 82 |                  TABLE ACCESS BY INDEX ROWID     | OE_ORDER_HEADERS_ALL          |     1 |    60 |     1 |
|* 83 |                   INDEX UNIQUE SCAN              | OE_ORDER_HEADERS_U1           |     1 |       |       |
|* 84 |                 TABLE ACCESS BY INDEX ROWID      | HZ_CUST_SITE_USES_ALL         |     1 |    21 |     2 |
|* 85 |                  INDEX UNIQUE SCAN               | HZ_CUST_SITE_USES_U1          |     1 |       |     1 |
|* 86 |                TABLE ACCESS BY INDEX ROWID       | HZ_CUST_SITE_USES_ALL         |     1 |    40 |     2 |
|* 87 |                 INDEX UNIQUE SCAN                | HZ_CUST_SITE_USES_U1          |     1 |       |     1 |
| 88 |               TABLE ACCESS BY INDEX ROWID        | WSH_CARRIERS                  |     1 |    26 |     1 |
|* 89 |                INDEX UNIQUE SCAN                 | WSH_CARRIERS_U2               |     1 |       |       |
|* 90 |              TABLE ACCESS BY INDEX ROWID         | WSH_CARRIER_SERVICES          |     1 |    69 |     1 |
|* 91 |               INDEX RANGE SCAN                   | WSH_CARRIER_SERVICES_N1       |     2 |       |       |
|* 92 |             TABLE ACCESS BY INDEX ROWID          | WSH_ORG_CARRIER_SERVICES      |     1 |     9 |     1 |
|* 93 |              INDEX RANGE SCAN                    | WSH_ORG_CARRIER_SERVICES_N1   |     1 |       |       |
| 94 |            TABLE ACCESS BY INDEX ROWID           | HZ_CUST_ACCOUNTS              |     1 |    19 |     2 |
|* 95 |             INDEX UNIQUE SCAN                    | HZ_CUST_ACCOUNTS_U1           |     1 |       |     1 |
|* 96 |           TABLE ACCESS BY INDEX ROWID            | HZ_CUST_ACCT_SITES_ALL        |     1 |    23 |     2 |
|* 97 |            INDEX UNIQUE SCAN                     | HZ_CUST_ACCT_SITES_U1         |     1 |       |     1 |
|* 98 |          TABLE ACCESS BY INDEX ROWID             | HZ_CUST_ACCT_SITES_ALL        |     1 |    25 |     2 |
|* 99 |           INDEX UNIQUE SCAN                      | HZ_CUST_ACCT_SITES_U1         |     1 |       |     1 |
| 100 |         TABLE ACCESS BY INDEX ROWID              | HZ_PARTY_SITES                |     1 |    12 |     2 |
PLAN_TABLE_OUTPUT
|*101 |          INDEX UNIQUE SCAN                       | HZ_PARTY_SITES_U1             |     1 |       |     1 |
| 102 |        TABLE ACCESS BY INDEX ROWID               | HZ_LOCATIONS                  |     1 |    59 |     2 |
|*103 |         INDEX UNIQUE SCAN                        | HZ_LOCATIONS_U1               |     1 |       |     1 |
|*104 |       INDEX RANGE SCAN                           | HZ_LOC_ASSIGNMENTS_N1         |     1 |    11 |     2 |
| 105 |      TABLE ACCESS BY INDEX ROWID                 | HZ_PARTY_SITES                |     1 |    12 |     2 |
|*106 |       INDEX UNIQUE SCAN                          | HZ_PARTY_SITES_U1             |     1 |       |     1 |
| 107 |     TABLE ACCESS BY INDEX ROWID                  | HZ_LOCATIONS                  |     1 |    52 |     2 |
|*108 |      INDEX UNIQUE SCAN                           | HZ_LOCATIONS_U1               |     1 |       |     1 |
|*109 |    INDEX RANGE SCAN                              | HZ_LOC_ASSIGNMENTS_N1         |     1 |    15 |     2 |
|*110 |   INDEX UNIQUE SCAN                              | HZ_PARTIES_U1                 |     1 |     5 |     1 |
I will put the predicate information in another post.
193 rows selected.
SQL> spool offPlease suggest on how can we improve the performance.
Regards,
Sreekanth Munagala.

Query taking too long to finish

Hi,
I'm running a query which is
Delete from msg where ID IN (select ID from deletedtrans );
It's taking too long to complete, it has been running for 24 hours already and not completed executing the query, I cancelled the query. I don't understand why it's taking too long, does anyone have any idea? I feel that this query should not take too long to complete

That seems to be too small piece of information to comment anything.
1. How many records are there in "deletedtrans" table ?
2. How many records from "msg" table are expected to be deleted ?
3. Are statistics up-to-date on "msg" and "deletedtrans" tables ?
4. Is "ID" column defined as NULL or NOT NULL in both "msg" and "deletedtrans" tables ? (Not sure whether this will cause any problem, but...)
5. Is this statement being executed when other users/applications are accessing/updating "msg" table ?

Connect by taking too long

Hello,
I have a table "a" that has:
left_id right_id type
4 5 1
4 6 1
4 7 1
5 9 2
5 10 2
5 11 2
9 13 3
13 14 4
10 15 3
QUERY:
select left_id, right_id, type from
a
connect by left_id = prior right_id
start with left_id = 4;
Execution Plan
Plan hash value: 2739023583
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 29 | 1131 | 18 (12)| 00:00:01 |
|* 1 | CONNECT BY WITH FILTERING| | | | | |
|* 2 | INDEX RANGE SCAN | a_PK | 5 | 65 | 3 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 24 | 624 | 13 (0)| 00:00:01 |
| 4 | CONNECT BY PUMP | | | | | |
|* 5 | INDEX RANGE SCAN | a_PK | 5 | 65 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("LEFT_ID"=PRIOR "RIGHT_ID")
2 - access("LEFT_ID"=4)
5 - access("LEFT_ID"="connect$_by$_pump$_002"."prior right_id ")
Is there a way to optimize the query?
The query is taking too long.
-Thanks
Karthik
Edited by: user3934098 on Nov 14, 2010 1:50 AM

Here is the detailed explaination:
Version: oracle 10g R2
Create table statement:
CREATE TABLE A
"LEFT_ID" NUMBER(9,0) NOT NULL ENABLE,
"RIGHT_ID" NUMBER(9,0) NOT NULL ENABLE,
"TYPE" NUMBER(9,0) NOT NULL ENABLE,
CONSTRAINT "A_PK" PRIMARY KEY ("LEFT_ID", "RIGHT_ID", "TYPE") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DATA" ENABLE,
CONSTRAINT "A_FK1" FOREIGN KEY ("TYPE") REFERENCES "B" ("TYPE") ENABLE
SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT
TABLESPACE "DATA" ;
Insert statements:
INSERT INTO A VALUES(4, 5, 1);
INSERT INTO A VALUES(4, 6, 1);
INSERT INTO A VALUES(4, 7, 1);
INSERT INTO A VALUES(5, 9, 2);
INSERT INTO A VALUES(5, 10, 2);
INSERT INTO A VALUES(5, 11, 2);
INSERT INTO A VALUES(9, 13, 3);
INSERT INTO A VALUES(13, 14, 4);
INSERT INTO A VALUES(10, 15, 3);
INDEXES:
CREATE UNIQUE INDEX "A_PK" ON "A" ("LEFT_ID", "RIGHT_ID", "TYPE") PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DATA" ;
QUERY:
select left_id, right_id, type from
a
connect by left_id = prior right_id
start with left_id = 4;
THE table has 951053 rows
The explain plan is:"
Execution Plan
Plan hash value: 2739023583
Id Operation Name Rows Bytes Cost (%CPU) Time
0 SELECT STATEMENT 29 1131 18 (12) 00:00:01
* 1 CONNECT BY WITH FILTERING
* 2 INDEX RANGE SCAN a_PK 5 65 3 (0) 00:00:01
3 NESTED LOOPS 24 624 13 (0) 00:00:01
4 CONNECT BY PUMP
* 5 INDEX RANGE SCAN a_PK 5 65 2 (0) 00:00:01
Predicate Information (identified by operation id):
1 - access("LEFT_ID"=PRIOR "RIGHT_ID")
2 - access("LEFT_ID"=4)
5 - access("LEFT_ID"="connect$_by$_pump$_002"."prior right_id ")
Now is there a way to optimize the query? The query takes about a min to excute. This will be my inner query.
" Is there any other information that you may need? Am I missing something here? "
-Thanks
Karthik
Edited by: user3934098 on Nov 14, 2010 2:22 AM

Data Archive Script is taking too long to delete a large table

Hi All,
We have data archive scripts, these scripts move data for a date range to a different table. so the script has two parts first copy data from original table to archive table; and second delete copied rows from the original table. The first part is executing very fast but the deletion is taking too long i.e. around 2-3 hours. The customer analysed the delete query and are saying the script is not using index and is going into full table scan. but the predicate itself is the primary key, Please help... More info below
CREATE TABLE "APP"."MON_TXNS"
   (    "ID_TXN" NUMBER(12,0) NOT NULL ENABLE,
    "BOL_IS_CANCELLED" VARCHAR2(1 BYTE) DEFAULT 'N' NOT NULL ENABLE,
    "ID_PAYER" NUMBER(12,0),
    "ID_PAYER_PI" NUMBER(12,0),
    "ID_PAYEE" NUMBER(12,0),
    "ID_PAYEE_PI" NUMBER(12,0),
    "ID_CURRENCY" CHAR(3 BYTE) NOT NULL ENABLE,
    "STR_TEXT" VARCHAR2(60 CHAR),
    "DAT_MERCHANT_TIMESTAMP" DATE,
    "STR_MERCHANT_ORDER_ID" VARCHAR2(30 BYTE),
    "DAT_EXPIRATION" DATE,
    "DAT_CREATION" DATE,
    "STR_USER_CREATION" VARCHAR2(30 CHAR),
    "DAT_LAST_UPDATE" DATE,
    "STR_USER_LAST_UPDATE" VARCHAR2(30 CHAR),
    "STR_OTP" CHAR(6 BYTE),
    "ID_AUTH_METHOD_PAYER" NUMBER(1,0),
    "AMNT_AMOUNT" NUMBER(23,0) DEFAULT 0,
    "BOL_IS_AUTOCAPTURE" VARCHAR2(1 BYTE) DEFAULT 'N' NOT NULL ENABLE,
    "ID_USE_CASE" NUMBER(4,0) NOT NULL ENABLE,
    "ID_AUTH_METHOD_PAYEE" NUMBER(2,0),
     CONSTRAINT "CKC_BOL_IS_CANCELLED_MON_TXNS" CHECK (BOL_IS_CANCELLED in ('Y','N')) ENABLE,
     CONSTRAINT "PK_MON_TXNS" PRIMARY KEY ("ID_TXN")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ENABLE,
     CONSTRAINT "FK_MON_TXNS_CURRENCIES" FOREIGN KEY ("ID_CURRENCY")
      REFERENCES "APP"."CURRENCIES" ("ID_CURRENCY") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PAYER" FOREIGN KEY ("ID_PAYER")
      REFERENCES "APP"."CUSTOMERS" ("ID_CUSTOMER") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PAYEE" FOREIGN KEY ("ID_PAYEE")
      REFERENCES "APP"."CUSTOMERS" ("ID_CUSTOMER") ENABLE,
     CONSTRAINT "FK_MON_TXNS_REFERENCE_TXNS" FOREIGN KEY ("ID_TXN")
      REFERENCES "APP"."TXNS" ("ID_TXN") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PI_PAYER" FOREIGN KEY ("ID_PAYER_PI")
      REFERENCES "APP"."PIS" ("ID_PI") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PI_PAYEE" FOREIGN KEY ("ID_PAYEE_PI")
      REFERENCES "APP"."PIS" ("ID_PI") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_AUTHMETHOD" FOREIGN KEY ("ID_AUTH_METHOD_PAYER")
      REFERENCES "APP"."AUTHENTICATION_METHODS" ("ID_AUTHENTICATION_METHOD") ENABLE,
     CONSTRAINT "FK_MON_TXNS_USE_CASE_ID" FOREIGN KEY ("ID_USE_CASE")
      REFERENCES "APP"."USE_CASES" ("ID_USE_CASE") ENABLE,
     CONSTRAINT "FK_MON_TXN_AUTH_PAYEE" FOREIGN KEY ("ID_AUTH_METHOD_PAYEE")
      REFERENCES "APP"."AUTHENTICATION_METHODS" ("ID_AUTHENTICATION_METHOD") ENABLE
CREATE INDEX "APP"."IDX_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYER")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ;
CREATE INDEX "APP"."IDX_PAYEE_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYEE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_PYE_PI_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYEE_PI")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_PYR_PI_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYER_PI")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_USE_CASE_MON_TXNS" ON "APP"."MON_TXNS" ("ID_USE_CASE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE UNIQUE INDEX "APP"."PK_MON_TXNS" ON "APP"."MON_TXNS" ("ID_TXN")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ;
Data is first moved to table in schema3.OTW. and then we are deleting all the rows in otw from original table. below is the explain plan for delete
SQL> explain plan for
2 delete from schema1.mon_txns where id_txn in (select id_txn from schema3.OTW);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2798378986
| Id | Operation              | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | DELETE STATEMENT       |            | 2520 |   233K|    87   (2)| 00:00:02 |
|   1 | DELETE                | MON_TXNS   |       |       |            |          |
|* 2 |   HASH JOIN RIGHT SEMI |            | 2520 |   233K|    87   (2)| 00:00:02 |
|   3 |    INDEX FAST FULL SCAN| OTW_ID_TXN | 2520 | 15120 |     3   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL   | MON_TXNS   | 14260 | 1239K|    83   (0)| 00:00:02 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
Please help,
thanks,
Banka Ravi

'Best practice' is just what Oracle is already doing as you have already been told: DELETE FROM myTable WHERE myDate between myStart and Myend.
Your use case is why many orgs elect to use partitioning and use that DATE column as the partition key. Then it is VERY FAST and VERY EASY to truncate or drop partitions that contain old data when you no longer need them.
The other solution used is to quit waiting so long to delete data and then you don't have to delete large amounts at the same time. So instead of deleting data once a month delete it once a week or even every night. Then the number of rows being deleted will be much smaller and, if the stats are kept current, Oracle may decide to use the index.

Data manager jobs taking too long or hanging

Hoping someone here can provide some assistance with regard to the 4.2 version. We are specifically using BPC/OutlookSoft 4.2SP4 (and in process of upgrading to BPC7.5). Three server environment - SQL, OLAP and Web.
Problem: Data manager jobs in each application of production appset with five applications are either taking too long to complete for very small jobs (single entity/single period data copy/clear, under 1000 records) or completely hanging for larger jobs. This has been an issue for the last 7 days. During normal operation, small DM jobs ran in under a minute and large ones taking only a few minutes.
Failed attempts at resolution thus far:
1. Processed all applications from the OLAP server
2. Confirmed issue is specific to our appset and is not present in ApShell
3. Copied packages from ApShell to application to eliminate package corruption
4. Windows security updates were applied to all three servers but I assume this would also impact ApShell.
5. Cleared tblDTSLog history
6. Rebooted all three servers
7. Suspected antivirus however, problem persists with antivirus disabled on all three servers.
Other Observations
There are several tables in the SQL database named k2import# and several stored procedures named DMU_k2import#. My guess is these did not get removed because I killed the hung up jobs. I'm not sure if their existence is causing any issues.
To make the long story short, how can I narrow down at which point the jobs are hanging up or what is taking the longest time? I have turned on Debug Script but I don't' have documentation to make sense of all this info. What exactly is happening when I run a Clear package? At this point, my next step is to run SQL Profiler to get a look into what is going on behind the scenes on the sql server. I also want to rule out the COM+ objects on the web server but not sure where to start.
Any help is greatly appreciated!!
Thank you,
Hitesh

Hi ,
The problem seems to be related to database. Do you have any maintenance plan for database?
It is specific for your appset because each appset has own database.
I suspect you have to run an sp_updatestats (Update Statistics) for your database and I think the issue with your jobs hang will be solved.
DMU_K2_importXXX table are coming from hang imports ...you can delete these tables because it is just growing the size of database and for sure are not used anymore.
Regards
Sorin Radulescu

Skype is taking too long to login

I open up skype and type in my username and password, but it's taking longer than it ever should to sign in
I have windows 8.1
Solved!
Go to Solution.

ampylagria1411 wrote:
after waiting for a long time for skype to log in, it just suddenly goes back to the display box for name and password, and shows the statement "skype can't connect". why is it that it's taking too long to log in?
What Firewall and Antivirus applications are installed on your computer?

Discoverer report taking too long time to open.

HI,
Discovere reports are taking too long time to open. Please help to resolve this.
Regards,
Bhatia

What is the Dicoverer and the Application release?
Please refer to the following links (For both Discoverer 4i and 10g). Please note that some Discoverer 4i notes also apply to Discoverer 10g.
Note: 362851.1 - Guidelines to setup the JVM in Apps Ebusiness Suite 11i and R12
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=362851.1
Note: 68100.1 - Discoverer Performance When Running On Oracle Applications
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=68100.1
Note: 465234.1 - Recommended Client Java Plug-in (JVM/JRE) For Discoverer Plus 10g (10.1.2)
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=465234.1
Note: 329674.1 - Slow Performance When Opening Plus Workbooks from Oracle 11.5.10 Applications Home Page
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=329674.1
Note: 190326.1 - Ideas for Improving Discoverer 4i Performance in an Applications 11i Environment
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=190326.1
Note: 331435.1 - Slow Perfomance Using Disco 4.1 Admin/Desktop in Oracle Applications Mode EUL
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=331435.1
Note: 217669.1 - Refreshing Folders and opening workbooks is slow in Apps 11i environment
https://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=217669.1

Browser times out when trying to view my website - says the server is taking too long. And no, I don't have a firewall.

I can't view my website at www.artisancandies.com, even though it's working and everyone else seems to see it. No, I don't have a firewall, and it's not because of my internet provider - I have AT&T at work, and Comcast at home. My husband can see the site on his laptop. I tried dumping my cache in both Firefox and Safari, but it didn't work. I looked at it through proxify.com, and can see it that way, so I know it works. This is so frustrating, because I used to only see it when I typed in artisancandies.com - it would never work for me if I typed in www.artisancandies.com. Now it doesn't work at all. This is the message I get in Firefox:
"The connection has timed out. The server at www.artisancandies.com is taking too long to respond."
Please help!!!
Kristen Scott

Linc, here's what I've got from what you asked me to do. I hope you don't mind, but it was simple enough to leave everything in, so you could see the progression:
Kristen-Scotts-Computer:~ kristenscott$ kextstat -kl | awk ' !/apple/ { print $6 $7 } '
Kristen-Scotts-Computer:~ kristenscott$ sudo launchctl list | sed 1d | awk ' !/0x|apple|com\.vix|edu\.|org\./ { print $3 } '
WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.
To proceed, enter your password, or type Ctrl-C to abort.
Password:
com.microsoft.office.licensing.helper
com.google.keystone.daemon
com.adobe.versioncueCS3
Kristen-Scotts-Computer:~ kristenscott$ launchctl list | sed 1d | awk ' !/0x|apple|edu\.|org\./ { print $3 } '
com.google.keystone.root.agent
com.adobe.ARM.202f4087f2bbde52e3ac2df389f53a4f123223c9cc56a8fd83a6f7ae
Kristen-Scotts-Computer:~ kristenscott$ ls -1A {,/}Library/{Ad,Compon,Ex,Fram,In,La,Mail/Bu,P*P,Priv,Qu,Scripti,Sta}* 2> /dev/null
/Library/Components:
/Library/Extensions:
/Library/Frameworks:
Adobe AIR.framework
NyxAudioAnalysis.framework
PluginManager.framework
iLifeFaceRecognition.framework
iLifeKit.framework
iLifePageLayout.framework
iLifeSQLAccess.framework
iLifeSlideshow.framework
/Library/Input Methods:
/Library/Internet Plug-Ins:
AdobePDFViewer.plugin
Disabled Plug-Ins
Flash Player.plugin
Flip4Mac WMV Plugin.plugin
Flip4Mac WMV Plugin.webplugin
Google Earth Web Plug-in.plugin
JavaPlugin2_NPAPI.plugin
JavaPluginCocoa.bundle
Musicnotes.plugin
NP-PPC-Dir-Shockwave
Quartz Composer.webplugin
QuickTime Plugin.plugin
Scorch.plugin
SharePointBrowserPlugin.plugin
SharePointWebKitPlugin.webplugin
flashplayer.xpt
googletalkbrowserplugin.plugin
iPhotoPhotocast.plugin
npgtpo3dautoplugin.plugin
nsIQTScriptablePlugin.xpt
/Library/LaunchAgents:
com.google.keystone.agent.plist
/Library/LaunchDaemons:
com.adobe.versioncueCS3.plist
com.apple.third_party_32b_kext_logger.plist
com.google.keystone.daemon.plist
com.microsoft.office.licensing.helper.plist
/Library/PreferencePanes:
Flash Player.prefPane
Flip4Mac WMV.prefPane
VersionCue.prefPane
VersionCueCS3.prefPane
/Library/PrivilegedHelperTools:
com.microsoft.office.licensing.helper
/Library/QuickLook:
GBQLGenerator.qlgenerator
iWork.qlgenerator
/Library/QuickTime:
AppleIntermediateCodec.component
AppleMPEG2Codec.component
Flip4Mac WMV Export.component
Flip4Mac WMV Import.component
Google Camera Adapter 0.component
Google Camera Adapter 1.component
/Library/ScriptingAdditions:
Adobe Unit Types
Adobe Unit Types.osax
/Library/StartupItems:
AdobeVersionCue
HP Trap Monitor
Library/Address Book Plug-Ins:
SkypeABDialer.bundle
SkypeABSMS.bundle
Library/Internet Plug-Ins:
Move_Media_Player.plugin
fbplugin_1_0_1.plugin
Library/LaunchAgents:
com.adobe.ARM.202f4087f2bbde52e3ac2df389f53a4f123223c9cc56a8fd83a6f7ae.plist
com.apple.FolderActions.enabled.plist
com.apple.FolderActions.folders.plist
Library/PreferencePanes:
A Better Finder Preferences.prefPane
Kristen-Scotts-Computer:~ kristenscott$

Purge Stats History taking too long

Similar Messages

Maybe you are looking for