Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

select into query slow..

6 posts in General Discussion Last posting was on 2012-10-22 23:45:39.0Z
Raj Posted on 2012-10-20 10:55:25.0Z
Sender: 4cbf.50828185.1804289383@sybase.com
From: Raj
Newsgroups: sybase.public.ase.general
Subject: select into query slow..
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <5082831c.4d3b.1681692777@sybase.com>
NNTP-Posting-Host: 172.20.134.41
X-Original-NNTP-Posting-Host: 172.20.134.41
Date: 20 Oct 2012 03:55:25 -0700
X-Trace: forums-1-dub 1350730525 172.20.134.41 (20 Oct 2012 03:55:25 -0700)
X-Original-Trace: 20 Oct 2012 03:55:25 -0700, 172.20.134.41
Lines: 12
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31458
Article PK: 74345

Hi,

What could be possble reasons for slowness of select into
query(select * into table1 from table2) ?
I know it's a vague question. This query is taking around 2
hours on a table has 2.3 million rows. We are running ASE
15.7 ESD#2 on AIX 6.1. would like to know what are the areas
I should look at, could be causing this slowness ?


Thanks in advance,
Raj


"Mark A. Parsons" <iron_horse Posted on 2012-10-20 18:02:04.0Z
From: "Mark A. Parsons" <iron_horse@no_spamola.compuserve.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: select into query slow..
References: <5082831c.4d3b.1681692777@sybase.com>
In-Reply-To: <5082831c.4d3b.1681692777@sybase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120916-1, 09/16/2012), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <5082e71c$1@forums-1-dub>
Date: 20 Oct 2012 11:02:04 -0700
X-Trace: forums-1-dub 1350756124 172.20.134.152 (20 Oct 2012 11:02:04 -0700)
X-Original-Trace: 20 Oct 2012 11:02:04 -0700, vip152.sybase.com
Lines: 19
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31459
Article PK: 74347

Have you ruled out any issues with the query plan?

While the query is running take snapshots of monProcessWaits (to see where delays are occurring) and monProcessObject
(to see if you're performing an excessive volume of physical/logical IOs on any tables/indexes).

On 10/20/2012 04:55, Raj wrote:
> Hi,
>
> What could be possble reasons for slowness of select into
> query(select * into table1 from table2) ?
> I know it's a vague question. This query is taking around 2
> hours on a table has 2.3 million rows. We are running ASE
> 15.7 ESD#2 on AIX 6.1. would like to know what are the areas
> I should look at, could be causing this slowness ?
>
>
> Thanks in advance,
> Raj


Raj Posted on 2012-10-22 08:44:56.0Z
Sender: 21ee.50850744.1804289383@sybase.com
From: Raj
Newsgroups: sybase.public.ase.general
Subject: Re: select into query slow..
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <50850788.2200.1681692777@sybase.com>
References: <5082e71c$1@forums-1-dub>
NNTP-Posting-Host: 172.20.134.41
X-Original-NNTP-Posting-Host: 172.20.134.41
Date: 22 Oct 2012 01:44:56 -0700
X-Trace: forums-1-dub 1350895496 172.20.134.41 (22 Oct 2012 01:44:56 -0700)
X-Original-Trace: 22 Oct 2012 01:44:56 -0700, 172.20.134.41
Lines: 91
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31460
Article PK: 74349

Hi Mark,

Query plan is below.


QUERY PLAN FOR STATEMENT 1 (at line 1).
Optimized using Serial Mode


STEP 1
The type of query is CREATE TABLE.

STEP 2
The type of query is INSERT.

|ROOT:EMIT Operator (VA = 2)

|
| |INSERT Operator (VA = 1)
| | The update mode is direct.
| |
| | |SCAN Operator (VA = 0)
| | | FROM TABLE
| | | table2
| | | Table Scan.
| | | Forward Scan.
| | | Positioning at start of table.
| | | Using I/O Size 32 Kbytes for data pages.
| | | With LRU Buffer Replacement Strategy for
data pages.
| |
| | TO TABLE
| | table1
| | Using I/O Size 32 Kbytes for data pages.



I see 14 million logical reads on the index and below is a
sanpshot of monProcessWaits during that time.


SPID InstanceID KPID ServerUserID WaitEventID
Waits WaitTime
----------- ---------- ----------- ------------ -----------
----------- -----------
628 0 205586976 80 29
272567 650800
628 0 205586976 80 31
512 1500
628 0 205586976 80 36
481 1500
628 0 205586976 80 51
3 0
628 0 205586976 80 55
3 0
628 0 205586976 80 124
36495 77900
628 0 205586976 80 214
34 0
628 0 205586976 80 250
4 0




Thanks,
Raj

> Have you ruled out any issues with the query plan?
>
> While the query is running take snapshots of
> monProcessWaits (to see where delays are occurring) and
> monProcessObject (to see if you're performing an
> excessive volume of physical/logical IOs on any
> tables/indexes).
>
>
> On 10/20/2012 04:55, Raj wrote:
> > Hi,
> >
> > What could be possble reasons for slowness of select
> > into query(select * into table1 from table2) ?
> > I know it's a vague question. This query is taking
> > around 2 hours on a table has 2.3 million rows. We are
> > running ASE 15.7 ESD#2 on AIX 6.1. would like to know
> > what are the areas I should look at, could be causing
> this slowness ? >
> >
> > Thanks in advance,
> > Raj


"Mark A. Parsons" <iron_horse Posted on 2012-10-22 13:23:41.0Z
From: "Mark A. Parsons" <iron_horse@no_spamola.compuserve.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: select into query slow..
References: <5082e71c$1@forums-1-dub> <50850788.2200.1681692777@sybase.com>
In-Reply-To: <50850788.2200.1681692777@sybase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120916-1, 09/16/2012), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <508548dd$1@forums-1-dub>
Date: 22 Oct 2012 06:23:41 -0700
X-Trace: forums-1-dub 1350912221 172.20.134.152 (22 Oct 2012 06:23:41 -0700)
X-Original-Trace: 22 Oct 2012 06:23:41 -0700, vip152.sybase.com
Lines: 104
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31461
Article PK: 74350

The waits show a lot of physical IOs requiring an average of 2.3ms to complete.

There's also some contention (event id = 124) with something else also reading the table.

Your comment about the index requiring 14M logical reads for an *index* doesn't make sense in that your query plan shows
no index usage.

What is the size of the source table? (sp_spaceused <table_name>,1)

What does your cache configuration look like? (sp_cacheconfig)

On 10/22/2012 02:44, Raj wrote:
> Hi Mark,
>
> Query plan is below.
>
>
> QUERY PLAN FOR STATEMENT 1 (at line 1).
> Optimized using Serial Mode
>
>
> STEP 1
> The type of query is CREATE TABLE.
>
> STEP 2
> The type of query is INSERT.
>
>
> |ROOT:EMIT Operator (VA = 2)
> |
> | |INSERT Operator (VA = 1)
> | | The update mode is direct.
> | |
> | | |SCAN Operator (VA = 0)
> | | | FROM TABLE
> | | | table2
> | | | Table Scan.
> | | | Forward Scan.
> | | | Positioning at start of table.
> | | | Using I/O Size 32 Kbytes for data pages.
> | | | With LRU Buffer Replacement Strategy for
> data pages.
> | |
> | | TO TABLE
> | | table1
> | | Using I/O Size 32 Kbytes for data pages.
>
>
>
> I see 14 million logical reads on the index and below is a
> sanpshot of monProcessWaits during that time.
>
>
> SPID InstanceID KPID ServerUserID WaitEventID
> Waits WaitTime
> ----------- ---------- ----------- ------------ -----------
> ----------- -----------
> 628 0 205586976 80 29
> 272567 650800
> 628 0 205586976 80 31
> 512 1500
> 628 0 205586976 80 36
> 481 1500
> 628 0 205586976 80 51
> 3 0
> 628 0 205586976 80 55
> 3 0
> 628 0 205586976 80 124
> 36495 77900
> 628 0 205586976 80 214
> 34 0
> 628 0 205586976 80 250
> 4 0
>
>
>
>
> Thanks,
> Raj
>
>> Have you ruled out any issues with the query plan?
>>
>> While the query is running take snapshots of
>> monProcessWaits (to see where delays are occurring) and
>> monProcessObject (to see if you're performing an
>> excessive volume of physical/logical IOs on any
>> tables/indexes).
>>
>>
>> On 10/20/2012 04:55, Raj wrote:
>>> Hi,
>>>
>>> What could be possble reasons for slowness of select
>>> into query(select * into table1 from table2) ?
>>> I know it's a vague question. This query is taking
>>> around 2 hours on a table has 2.3 million rows. We are
>>> running ASE 15.7 ESD#2 on AIX 6.1. would like to know
>>> what are the areas I should look at, could be causing
>> this slowness ?>
>>>
>>> Thanks in advance,
>>> Raj


Raj Posted on 2012-10-22 22:19:52.0Z
Sender: 56af.5085c56f.1804289383@sybase.com
From: Raj
Newsgroups: sybase.public.ase.general
Subject: Re: select into query slow..
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <5085c688.56fa.1681692777@sybase.com>
References: <508548dd$1@forums-1-dub>
NNTP-Posting-Host: 172.20.134.41
X-Original-NNTP-Posting-Host: 172.20.134.41
Date: 22 Oct 2012 15:19:52 -0700
X-Trace: forums-1-dub 1350944392 172.20.134.41 (22 Oct 2012 15:19:52 -0700)
X-Original-Trace: 22 Oct 2012 15:19:52 -0700, 172.20.134.41
Lines: 193
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31464
Article PK: 74352

Hi Mark,

sp_spaceused and sp_cacheconfig outputs are below. Just to
let you know, tempdb is in memory.


1> sp_spaceused 'table2',1
2> go
index_name size reserved unused
--------------------------- ---------- ---------- --------
table2_ND0 35484 KB 35644 KB 160 KB
ttable2 11717164 K 11757684 K 40520 KB

(1 row affected)
name rowtotal reserved data
index_size unused
----------------------- -------- ----------- ---------
----------- --------
table2 2385513 11922240 KB 128864 KB
11752648 KB 40728 KB
(return status = 0)



1> sp_cacheconfig
2> go
Cache Name Status Type Config Value Run
Value
------------------ -------- -------- --------------
------------
dbcc_cache Active Mixed 5000.00 Mb
5000.00 Mb
default data cache Active Default 35000.00 Mb
35000.00 Mb
tempdb_cache Active Mixed 2000.00 Mb
2000.00 Mb

(1 row affected)
------------ ------------
Total 42000.0 Mb 42000.0 Mb
==========================================================================
Cache: dbcc_cache, Status: Active, Type: Mixed
Config Size: 5000.00 Mb, Run Size: 5000.00 Mb
Config Replacement: strict LRU, Run Replacement:
strict LRU
Config Partition: 1, Run Partition:
1
IO Size Wash Size Config Size Run Size APF
Percent
-------- ------------- ------------ ------------
-----------
4 Kb 61440 Kb 2000.00 Mb 2000.00 Mb 10
32 Kb 61440 Kb 3000.00 Mb 3000.00 Mb 10
==========================================================================
Cache: default data cache, Status: Active, Type: Default
Config Size: 35000.00 Mb, Run Size: 35000.00 Mb
Config Replacement: strict LRU, Run Replacement:
strict LRU
Config Partition: 8, Run Partition:
8
IO Size Wash Size Config Size Run Size APF
Percent
-------- ------------- ------------ ------------
-----------
4 Kb 491520 Kb 20000.00 Mb 20000.00 Mb 10
32 Kb 491520 Kb 15000.00 Mb 15000.00 Mb 50
==========================================================================
Cache: tempdb_cache, Status: Active, Type: Mixed
Config Size: 2000.00 Mb, Run Size: 2000.00 Mb
Config Replacement: strict LRU, Run Replacement:
strict LRU
Config Partition: 1, Run Partition:
1
IO Size Wash Size Config Size Run Size APF
Percent
-------- ------------- ------------ ------------
-----------
4 Kb 61440 Kb 2000.00 Mb 2000.00 Mb 10



Thanks,
Raj

> The waits show a lot of physical IOs requiring an average
> of 2.3ms to complete.
>
> There's also some contention (event id = 124) with
> something else also reading the table.
>
> Your comment about the index requiring 14M logical reads
> for an *index* doesn't make sense in that your query plan
> shows no index usage.
>
> What is the size of the source table? (sp_spaceused
> <table_name>,1)
>
> What does your cache configuration look like?
> (sp_cacheconfig)
>
>
>
> On 10/22/2012 02:44, Raj wrote:
> > Hi Mark,
> >
> > Query plan is below.
> >
> >
> > QUERY PLAN FOR STATEMENT 1 (at line 1).
> > Optimized using Serial Mode
> >
> >
> > STEP 1
> > The type of query is CREATE TABLE.
> >
> > STEP 2
> > The type of query is INSERT.
> >
> >
> > |ROOT:EMIT Operator (VA = 2)
> > |
> > | |INSERT Operator (VA = 1)
> > | | The update mode is direct.
> > | |
> > | | |SCAN Operator (VA = 0)
> > | | | FROM TABLE
> > | | | table2
> > | | | Table Scan.
> > | | | Forward Scan.
> > | | | Positioning at start of table.
> > | | | Using I/O Size 32 Kbytes for data
> > pages. | | | With LRU Buffer Replacement
> > Strategy for data pages.
> > | |
> > | | TO TABLE
> > | | table1
> > | | Using I/O Size 32 Kbytes for data pages.
> >
> >
> >
> > I see 14 million logical reads on the index and below is
> > a sanpshot of monProcessWaits during that time.
> >
> >
> > SPID InstanceID KPID ServerUserID
> > WaitEventID Waits WaitTime
> > ----------- ---------- ----------- ------------
> > ----------- ----------- -----------
> > 628 0 205586976 80
> > 29 272567 650800
> > 628 0 205586976 80
> > 31 512 1500
> > 628 0 205586976 80
> > 36 481 1500
> > 628 0 205586976 80
> > 51 3 0
> > 628 0 205586976 80
> > 55 3 0
> > 628 0 205586976 80
> > 124 36495 77900
> > 628 0 205586976 80
> > 214 34 0
> > 628 0 205586976 80
> > 250 4 0
> >
> >
> >
> >
> > Thanks,
> > Raj
> >
> >> Have you ruled out any issues with the query plan?
> >>
> >> While the query is running take snapshots of
> >> monProcessWaits (to see where delays are occurring) and
> >> monProcessObject (to see if you're performing an
> >> excessive volume of physical/logical IOs on any
> >> tables/indexes).
> >>
> >>
> >> On 10/20/2012 04:55, Raj wrote:
> >>> Hi,
> >>>
> >>> What could be possble reasons for slowness of
> select >>> into query(select * into table1 from table2) ?
> >>> I know it's a vague question. This query is taking
> >>> around 2 hours on a table has 2.3 million rows. We are
> >>> running ASE 15.7 ESD#2 on AIX 6.1. would like to know
> >>> what are the areas I should look at, could be causing
> >> this slowness ?>
> >>>
> >>> Thanks in advance,
> >>> Raj


"Mark A. Parsons" <iron_horse Posted on 2012-10-22 23:45:39.0Z
From: "Mark A. Parsons" <iron_horse@no_spamola.compuserve.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: select into query slow..
References: <508548dd$1@forums-1-dub> <5085c688.56fa.1681692777@sybase.com>
In-Reply-To: <5085c688.56fa.1681692777@sybase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120916-1, 09/16/2012), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <5085daa3$1@forums-1-dub>
Date: 22 Oct 2012 16:45:39 -0700
X-Trace: forums-1-dub 1350949539 172.20.134.152 (22 Oct 2012 16:45:39 -0700)
X-Original-Trace: 22 Oct 2012 16:45:39 -0700, vip152.sybase.com
Lines: 219
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31465
Article PK: 74353

OK, so I'm *assuming* the previously mentioned *index* was in reference to indid=255 (ie, your blob chains).

While I would expect this type of query to take a bit longer due to having to follow the 2.38+ million blob chains, 2
hours still sounds a bit extreme.

Unfortunately we still only have snippets of what's happening, eg:

- we have a monProcessWaits snippet for just the first 12 minutes; have to guess what's going on the other 108 minutes

- we've been told the 'index' shows 14M logical IOs (from monProcessObject?) but no idea if that's for the entire run,
the first 12 minutes, or some other point in the middle of the run

- would be interesting to find out if your disk io configuration (disk io structures, server/engine max async ios) is
'too low' and thus introducing an artificial io bottleneck in the dataserver

I'd probably want to look at adding some parallelism to the mix (eg, multiple worker threads on the reads; potentially
parallel writes to multiple partitions - then merge the partitions back into 1 when done; etc).

A quick back-of-the-napkin calculation shows your blob chains are an average of 1 page in length ... would be
interesting to see how long most of your blobs really are. Assuming most blob chains are relatively small (eg, much
smaller than 4K) it might be interesting to see if 15.7's new inline lob capability would shrink this table down to
something more manageable (ie, eliminate many of the blob chains thus freeing up space and reducing time it takes to
scan - and write - your rows).

On 10/22/2012 16:19, Raj wrote:
> Hi Mark,
>
> sp_spaceused and sp_cacheconfig outputs are below. Just to
> let you know, tempdb is in memory.
>
>
> 1> sp_spaceused 'table2',1
> 2> go
> index_name size reserved unused
> --------------------------- ---------- ---------- --------
> table2_ND0 35484 KB 35644 KB 160 KB
> ttable2 11717164 K 11757684 K 40520 KB
>
> (1 row affected)
> name rowtotal reserved data
> index_size unused
> ----------------------- -------- ----------- ---------
> ----------- --------
> table2 2385513 11922240 KB 128864 KB
> 11752648 KB 40728 KB
> (return status = 0)
>
>
>
> 1> sp_cacheconfig
> 2> go
> Cache Name Status Type Config Value Run
> Value
> ------------------ -------- -------- --------------
> ------------
> dbcc_cache Active Mixed 5000.00 Mb
> 5000.00 Mb
> default data cache Active Default 35000.00 Mb
> 35000.00 Mb
> tempdb_cache Active Mixed 2000.00 Mb
> 2000.00 Mb
>
> (1 row affected)
> ------------ ------------
> Total 42000.0 Mb 42000.0 Mb
> ==========================================================================
> Cache: dbcc_cache, Status: Active, Type: Mixed
> Config Size: 5000.00 Mb, Run Size: 5000.00 Mb
> Config Replacement: strict LRU, Run Replacement:
> strict LRU
> Config Partition: 1, Run Partition:
> 1
> IO Size Wash Size Config Size Run Size APF
> Percent
> -------- ------------- ------------ ------------
> -----------
> 4 Kb 61440 Kb 2000.00 Mb 2000.00 Mb 10
> 32 Kb 61440 Kb 3000.00 Mb 3000.00 Mb 10
> ==========================================================================
> Cache: default data cache, Status: Active, Type: Default
> Config Size: 35000.00 Mb, Run Size: 35000.00 Mb
> Config Replacement: strict LRU, Run Replacement:
> strict LRU
> Config Partition: 8, Run Partition:
> 8
> IO Size Wash Size Config Size Run Size APF
> Percent
> -------- ------------- ------------ ------------
> -----------
> 4 Kb 491520 Kb 20000.00 Mb 20000.00 Mb 10
> 32 Kb 491520 Kb 15000.00 Mb 15000.00 Mb 50
> ==========================================================================
> Cache: tempdb_cache, Status: Active, Type: Mixed
> Config Size: 2000.00 Mb, Run Size: 2000.00 Mb
> Config Replacement: strict LRU, Run Replacement:
> strict LRU
> Config Partition: 1, Run Partition:
> 1
> IO Size Wash Size Config Size Run Size APF
> Percent
> -------- ------------- ------------ ------------
> -----------
> 4 Kb 61440 Kb 2000.00 Mb 2000.00 Mb 10
>
>
>
> Thanks,
> Raj
>
>> The waits show a lot of physical IOs requiring an average
>> of 2.3ms to complete.
>>
>> There's also some contention (event id = 124) with
>> something else also reading the table.
>>
>> Your comment about the index requiring 14M logical reads
>> for an *index* doesn't make sense in that your query plan
>> shows no index usage.
>>
>> What is the size of the source table? (sp_spaceused
>> <table_name>,1)
>>
>> What does your cache configuration look like?
>> (sp_cacheconfig)
>>
>>
>>
>> On 10/22/2012 02:44, Raj wrote:
>>> Hi Mark,
>>>
>>> Query plan is below.
>>>
>>>
>>> QUERY PLAN FOR STATEMENT 1 (at line 1).
>>> Optimized using Serial Mode
>>>
>>>
>>> STEP 1
>>> The type of query is CREATE TABLE.
>>>
>>> STEP 2
>>> The type of query is INSERT.
>>>
>>>
>>> |ROOT:EMIT Operator (VA = 2)
>>> |
>>> | |INSERT Operator (VA = 1)
>>> | | The update mode is direct.
>>> | |
>>> | | |SCAN Operator (VA = 0)
>>> | | | FROM TABLE
>>> | | | table2
>>> | | | Table Scan.
>>> | | | Forward Scan.
>>> | | | Positioning at start of table.
>>> | | | Using I/O Size 32 Kbytes for data
>>> pages. | | | With LRU Buffer Replacement
>>> Strategy for data pages.
>>> | |
>>> | | TO TABLE
>>> | | table1
>>> | | Using I/O Size 32 Kbytes for data pages.
>>>
>>>
>>>
>>> I see 14 million logical reads on the index and below is
>>> a sanpshot of monProcessWaits during that time.
>>>
>>>
>>> SPID InstanceID KPID ServerUserID
>>> WaitEventID Waits WaitTime
>>> ----------- ---------- ----------- ------------
>>> ----------- ----------- -----------
>>> 628 0 205586976 80
>>> 29 272567 650800
>>> 628 0 205586976 80
>>> 31 512 1500
>>> 628 0 205586976 80
>>> 36 481 1500
>>> 628 0 205586976 80
>>> 51 3 0
>>> 628 0 205586976 80
>>> 55 3 0
>>> 628 0 205586976 80
>>> 124 36495 77900
>>> 628 0 205586976 80
>>> 214 34 0
>>> 628 0 205586976 80
>>> 250 4 0
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Raj
>>>
>>>> Have you ruled out any issues with the query plan?
>>>>
>>>> While the query is running take snapshots of
>>>> monProcessWaits (to see where delays are occurring) and
>>>> monProcessObject (to see if you're performing an
>>>> excessive volume of physical/logical IOs on any
>>>> tables/indexes).
>>>>
>>>>
>>>> On 10/20/2012 04:55, Raj wrote:
>>>>> Hi,
>>>>>
>>>>> What could be possble reasons for slowness of
>> select>>> into query(select * into table1 from table2) ?
>>>>> I know it's a vague question. This query is taking
>>>>> around 2 hours on a table has 2.3 million rows. We are
>>>>> running ASE 15.7 ESD#2 on AIX 6.1. would like to know
>>>>> what are the areas I should look at, could be causing
>>>> this slowness ?>
>>>>>
>>>>> Thanks in advance,
>>>>> Raj