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.

need help!

8 posts in General Discussion Last posting was on 2010-11-29 21:40:48.0Z
Robert Densmore Posted on 2010-11-17 00:15:46.0Z
From: Robert Densmore <bdensmore@austin.rr.ignore.com>
Newsgroups: sybase.public.ase.general
Subject: need help!
Message-ID: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 16 Nov 2010 16:15:46 -0800
X-Trace: forums-1-dub 1289952946 10.22.241.152 (16 Nov 2010 16:15:46 -0800)
X-Original-Trace: 16 Nov 2010 16:15:46 -0800, vip152.sybase.com
Lines: 33
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29709
Article PK: 78938

I need some help with explaining the following:

We have a database used by the application as a temp working/storage
by the app (extreme transaction activity). Because we have so many
users hitting the same temp working/storage db, we have log semaphore
contention. So, we implemented a design to break up the one temp
working/storage db into 5 to get better throughput. 1/5th the users
would go to a separate db with it's own logsegment. This involved
creating 5 dbs with its own views, procs. Around 1000 procs and 200
views in each. We scaled the config params to account. But upon
implmentation, engine busy % went to 100% starting at 8am and
continuing. After reviewing MDA data, I am convinced there was no
code causing the 100% cpu. Nothing in sp_monitorconfig showed any
reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
to roll back to using the same one temp working/storage db. After
rolling back the app, cpu usage was still 100%. I had to actually
drop all the procs/views in the 5 dbs (which were not being used after
rollback) and after that, we returned to normal. These procs/views
were still in cache from before we rolled back the app. But after we
rolled back, engine cpu utilitzation still at 100%. After dropping
all the procs/views from the extra dbs (which were no longer being
used), cpu went back down to normal.

I am extremely perplexed.

Any thoughts on explaining this?

version is:
Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009


Bob


Robert Densmore Posted on 2010-11-17 00:59:06.0Z
From: Robert Densmore <bdensmore@austin.rr.ignore.com>
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
Message-ID: <f5a6e6piubv2h6lsjvh0ahfa4dkfdpfuor@4ax.com>
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 16 Nov 2010 16:59:06 -0800
X-Trace: forums-1-dub 1289955546 10.22.241.152 (16 Nov 2010 16:59:06 -0800)
X-Original-Trace: 16 Nov 2010 16:59:06 -0800, vip152.sybase.com
Lines: 42
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29710
Article PK: 78939

More info. We have 6 engines and all 6 pegged at 100%. Normally,
during heavy load around 60%.

Bob

On 16 Nov 2010 16:15:46 -0800, Robert Densmore

<bdensmore@austin.rr.ignore.com> wrote:

>I need some help with explaining the following:
>
>We have a database used by the application as a temp working/storage
>by the app (extreme transaction activity). Because we have so many
>users hitting the same temp working/storage db, we have log semaphore
>contention. So, we implemented a design to break up the one temp
>working/storage db into 5 to get better throughput. 1/5th the users
>would go to a separate db with it's own logsegment. This involved
>creating 5 dbs with its own views, procs. Around 1000 procs and 200
>views in each. We scaled the config params to account. But upon
>implmentation, engine busy % went to 100% starting at 8am and
>continuing. After reviewing MDA data, I am convinced there was no
>code causing the 100% cpu. Nothing in sp_monitorconfig showed any
>reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
>to roll back to using the same one temp working/storage db. After
>rolling back the app, cpu usage was still 100%. I had to actually
>drop all the procs/views in the 5 dbs (which were not being used after
>rollback) and after that, we returned to normal. These procs/views
>were still in cache from before we rolled back the app. But after we
>rolled back, engine cpu utilitzation still at 100%. After dropping
>all the procs/views from the extra dbs (which were no longer being
>used), cpu went back down to normal.
>
>I am extremely perplexed.
>
>Any thoughts on explaining this?
>
>version is:
>Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
>5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009
>
>
>Bob


IQRules Posted on 2010-11-17 03:09:34.0Z
From: IQRules <IQRules@noname.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com> <f5a6e6piubv2h6lsjvh0ahfa4dkfdpfuor@4ax.com>
In-Reply-To: <f5a6e6piubv2h6lsjvh0ahfa4dkfdpfuor@4ax.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4ce3476e@forums-1-dub>
Date: 16 Nov 2010 19:09:34 -0800
X-Trace: forums-1-dub 1289963374 10.22.241.152 (16 Nov 2010 19:09:34 -0800)
X-Original-Trace: 16 Nov 2010 19:09:34 -0800, vip152.sybase.com
Lines: 54
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29711
Article PK: 78940

So this is AIX LPAR, not standalone box.

Do you have right AIX vmo setting? Have you or SA read this doc, done by
Peter H Barnett.

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101429

On 11/16/2010 7:59 PM, Robert Densmore wrote:
> More info. We have 6 engines and all 6 pegged at 100%. Normally,
> during heavy load around 60%.
>
> Bob
>
> On 16 Nov 2010 16:15:46 -0800, Robert Densmore
> <bdensmore@austin.rr.ignore.com> wrote:
>
>> I need some help with explaining the following:
>>
>> We have a database used by the application as a temp working/storage
>> by the app (extreme transaction activity). Because we have so many
>> users hitting the same temp working/storage db, we have log semaphore
>> contention. So, we implemented a design to break up the one temp
>> working/storage db into 5 to get better throughput. 1/5th the users
>> would go to a separate db with it's own logsegment. This involved
>> creating 5 dbs with its own views, procs. Around 1000 procs and 200
>> views in each. We scaled the config params to account. But upon
>> implmentation, engine busy % went to 100% starting at 8am and
>> continuing. After reviewing MDA data, I am convinced there was no
>> code causing the 100% cpu. Nothing in sp_monitorconfig showed any
>> reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
>> to roll back to using the same one temp working/storage db. After
>> rolling back the app, cpu usage was still 100%. I had to actually
>> drop all the procs/views in the 5 dbs (which were not being used after
>> rollback) and after that, we returned to normal. These procs/views
>> were still in cache from before we rolled back the app. But after we
>> rolled back, engine cpu utilitzation still at 100%. After dropping
>> all the procs/views from the extra dbs (which were no longer being
>> used), cpu went back down to normal.
>>
>> I am extremely perplexed.
>>
>> Any thoughts on explaining this?
>>
>> version is:
>> Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
>> 5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009
>>
>>
>> Bob
>


J Posted on 2010-11-17 16:16:27.0Z
From: jtotally_bogus@sbcglobal.net (J)
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
Reply-To: J@bogusemailAddress.com
Message-ID: <4ce3feea.1645174656@forums.sybase.com>
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com> <f5a6e6piubv2h6lsjvh0ahfa4dkfdpfuor@4ax.com>
X-Newsreader: Forte Free Agent 1.21/32.243
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 17 Nov 2010 08:16:27 -0800
X-Trace: forums-1-dub 1290010587 10.22.241.152 (17 Nov 2010 08:16:27 -0800)
X-Original-Trace: 17 Nov 2010 08:16:27 -0800, vip152.sybase.com
Lines: 58
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29712
Article PK: 78941

On 16 Nov 2010 16:59:06 -0800, Robert Densmore
<bdensmore@austin.rr.ignore.com> wrote:

I'm no expert. If you normally run at 60% but you have huge bottleneck
in the form of a log semaphore wait but then you remove that
bottleneck you would expect the cpu to go up a great deal til you hit
the next bottleneck. So is it possible that you just don't have
enough cpu to remove this bottleneck or maybe you now run into
spinlock content somewhere.

Did you have sysmon data for that before and after and what did it
show?

Jay

>More info. We have 6 engines and all 6 pegged at 100%. Normally,
>during heavy load around 60%.
>
>Bob
>
>On 16 Nov 2010 16:15:46 -0800, Robert Densmore
><bdensmore@austin.rr.ignore.com> wrote:
>
>>I need some help with explaining the following:
>>
>>We have a database used by the application as a temp working/storage
>>by the app (extreme transaction activity). Because we have so many
>>users hitting the same temp working/storage db, we have log semaphore
>>contention. So, we implemented a design to break up the one temp
>>working/storage db into 5 to get better throughput. 1/5th the users
>>would go to a separate db with it's own logsegment. This involved
>>creating 5 dbs with its own views, procs. Around 1000 procs and 200
>>views in each. We scaled the config params to account. But upon
>>implmentation, engine busy % went to 100% starting at 8am and
>>continuing. After reviewing MDA data, I am convinced there was no
>>code causing the 100% cpu. Nothing in sp_monitorconfig showed any
>>reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
>>to roll back to using the same one temp working/storage db. After
>>rolling back the app, cpu usage was still 100%. I had to actually
>>drop all the procs/views in the 5 dbs (which were not being used after
>>rollback) and after that, we returned to normal. These procs/views
>>were still in cache from before we rolled back the app. But after we
>>rolled back, engine cpu utilitzation still at 100%. After dropping
>>all the procs/views from the extra dbs (which were no longer being
>>used), cpu went back down to normal.
>>
>>I am extremely perplexed.
>>
>>Any thoughts on explaining this?
>>
>>version is:
>>Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
>>5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009
>>
>>
>>Bob
>


Robert Densmore Posted on 2010-11-17 16:48:11.0Z
From: Robert Densmore <bdensmore@austin.rr.ignore.com>
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
Message-ID: <th18e69mue9o3tnlpbdba0b3f0mjnfn7qp@4ax.com>
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com> <f5a6e6piubv2h6lsjvh0ahfa4dkfdpfuor@4ax.com> <4ce3feea.1645174656@forums.sybase.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 17 Nov 2010 08:48:11 -0800
X-Trace: forums-1-dub 1290012491 10.22.241.152 (17 Nov 2010 08:48:11 -0800)
X-Original-Trace: 17 Nov 2010 08:48:11 -0800, vip152.sybase.com
Lines: 67
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29715
Article PK: 78944

Thanks, but don't think so because we rollback the app to the state
before implementation and cpu still was pegged. Only after dropping
the five fold increase in procs/views (which were no longer being
accessed, but were still in cache), did cpu go back to normal.

Bob

On 17 Nov 2010 08:16:27 -0800, jtotally_bogus@sbcglobal.net (J) wrote:

>On 16 Nov 2010 16:59:06 -0800, Robert Densmore
><bdensmore@austin.rr.ignore.com> wrote:
>
>I'm no expert. If you normally run at 60% but you have huge bottleneck
>in the form of a log semaphore wait but then you remove that
>bottleneck you would expect the cpu to go up a great deal til you hit
>the next bottleneck. So is it possible that you just don't have
>enough cpu to remove this bottleneck or maybe you now run into
>spinlock content somewhere.
>
>Did you have sysmon data for that before and after and what did it
>show?
>
>Jay
>
>>More info. We have 6 engines and all 6 pegged at 100%. Normally,
>>during heavy load around 60%.
>>
>>Bob
>>
>>On 16 Nov 2010 16:15:46 -0800, Robert Densmore
>><bdensmore@austin.rr.ignore.com> wrote:
>>
>>>I need some help with explaining the following:
>>>
>>>We have a database used by the application as a temp working/storage
>>>by the app (extreme transaction activity). Because we have so many
>>>users hitting the same temp working/storage db, we have log semaphore
>>>contention. So, we implemented a design to break up the one temp
>>>working/storage db into 5 to get better throughput. 1/5th the users
>>>would go to a separate db with it's own logsegment. This involved
>>>creating 5 dbs with its own views, procs. Around 1000 procs and 200
>>>views in each. We scaled the config params to account. But upon
>>>implmentation, engine busy % went to 100% starting at 8am and
>>>continuing. After reviewing MDA data, I am convinced there was no
>>>code causing the 100% cpu. Nothing in sp_monitorconfig showed any
>>>reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
>>>to roll back to using the same one temp working/storage db. After
>>>rolling back the app, cpu usage was still 100%. I had to actually
>>>drop all the procs/views in the 5 dbs (which were not being used after
>>>rollback) and after that, we returned to normal. These procs/views
>>>were still in cache from before we rolled back the app. But after we
>>>rolled back, engine cpu utilitzation still at 100%. After dropping
>>>all the procs/views from the extra dbs (which were no longer being
>>>used), cpu went back down to normal.
>>>
>>>I am extremely perplexed.
>>>
>>>Any thoughts on explaining this?
>>>
>>>version is:
>>>Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
>>>5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009
>>>
>>>
>>>Bob
>>


Bret Halford Posted on 2010-11-17 16:16:44.0Z
From: Bret Halford <bret@sybase.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com>
In-Reply-To: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4ce3ffec@forums-1-dub>
Date: 17 Nov 2010 08:16:44 -0800
X-Trace: forums-1-dub 1290010604 10.22.241.152 (17 Nov 2010 08:16:44 -0800)
X-Original-Trace: 17 Nov 2010 08:16:44 -0800, vip152.sybase.com
Lines: 44
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29713
Article PK: 78942


On 11/16/2010 5:15 PM, Robert Densmore wrote:
> I need some help with explaining the following:
>
> We have a database used by the application as a temp working/storage
> by the app (extreme transaction activity). Because we have so many
> users hitting the same temp working/storage db, we have log semaphore
> contention. So, we implemented a design to break up the one temp
> working/storage db into 5 to get better throughput. 1/5th the users
> would go to a separate db with it's own logsegment. This involved
> creating 5 dbs with its own views, procs. Around 1000 procs and 200
> views in each. We scaled the config params to account. But upon
> implmentation, engine busy % went to 100% starting at 8am and
> continuing. After reviewing MDA data, I am convinced there was no
> code causing the 100% cpu. Nothing in sp_monitorconfig showed any
> reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
> to roll back to using the same one temp working/storage db. After
> rolling back the app, cpu usage was still 100%. I had to actually
> drop all the procs/views in the 5 dbs (which were not being used after
> rollback) and after that, we returned to normal. These procs/views
> were still in cache from before we rolled back the app. But after we
> rolled back, engine cpu utilitzation still at 100%. After dropping
> all the procs/views from the extra dbs (which were no longer being
> used), cpu went back down to normal.
>
> I am extremely perplexed.
>
> Any thoughts on explaining this?
>
> version is:
> Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
> 5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009
>
>
> Bob

Sounds like doing this may have greatly increased the usage
of some resources such as open databases (up by 4), open
objects, open indexes, etc. Does sp_monitorconfig show
that any of these were being reused? Scavanging is a
fairly expensive operation, so that is one theory for the
CPU activity.

-bret


Robert Densmore Posted on 2010-11-17 16:34:22.0Z
From: Robert Densmore <bdensmore@austin.rr.ignore.com>
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
Message-ID: <fa08e61lqrla9p4tseci0eve9eqlp5vtgo@4ax.com>
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com> <4ce3ffec@forums-1-dub>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Date: 17 Nov 2010 08:34:22 -0800
X-Trace: forums-1-dub 1290011662 10.22.241.152 (17 Nov 2010 08:34:22 -0800)
X-Original-Trace: 17 Nov 2010 08:34:22 -0800, vip152.sybase.com
Lines: 55
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29714
Article PK: 78943


On 17 Nov 2010 08:16:44 -0800, Bret Halford <bret@sybase.com> wrote:

>On 11/16/2010 5:15 PM, Robert Densmore wrote:
>> I need some help with explaining the following:
>>
>> We have a database used by the application as a temp working/storage
>> by the app (extreme transaction activity). Because we have so many
>> users hitting the same temp working/storage db, we have log semaphore
>> contention. So, we implemented a design to break up the one temp
>> working/storage db into 5 to get better throughput. 1/5th the users
>> would go to a separate db with it's own logsegment. This involved
>> creating 5 dbs with its own views, procs. Around 1000 procs and 200
>> views in each. We scaled the config params to account. But upon
>> implmentation, engine busy % went to 100% starting at 8am and
>> continuing. After reviewing MDA data, I am convinced there was no
>> code causing the 100% cpu. Nothing in sp_monitorconfig showed any
>> reuse. No bad query plans, etc. No cpu intensive loops,etc. We had
>> to roll back to using the same one temp working/storage db. After
>> rolling back the app, cpu usage was still 100%. I had to actually
>> drop all the procs/views in the 5 dbs (which were not being used after
>> rollback) and after that, we returned to normal. These procs/views
>> were still in cache from before we rolled back the app. But after we
>> rolled back, engine cpu utilitzation still at 100%. After dropping
>> all the procs/views from the extra dbs (which were no longer being
>> used), cpu went back down to normal.
>>
>> I am extremely perplexed.
>>
>> Any thoughts on explaining this?
>>
>> version is:
>> Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2 ONE-OFF/P/RS6000/AIX
>> 5.3/ase1503/2708/64-bit/FBO/Wed Oct 14 11:17:45 2009
>>
>>
>> Bob
>
>Sounds like doing this may have greatly increased the usage
>of some resources such as open databases (up by 4), open
>objects, open indexes, etc. Does sp_monitorconfig show
>that any of these were being reused? Scavanging is a
>fairly expensive operation, so that is one theory for the
>CPU activity.
>
>-bret

There was no reuse indicated by sp_monitorconfig, but scavenging is
what I suspected, but couldn't find any proof of it. We bumped up
open databases, open indexes, open objects, open partitions, procedure
cache and number of locks, number of user connections appropriately.

We show reuse for permission cache entries but I understand from our
DBA that is a bug in ASE.

Bob


stupidone Posted on 2010-11-29 21:40:48.0Z
Sender: 6f2e.4cf3c8de.1804289383@sybase.com
From: stupidone
Newsgroups: sybase.public.ase.general
Subject: Re: need help!
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <4cf41de0.c9c.1681692777@sybase.com>
References: <e566e697de2e39hld3hs7e5n21ekuv829e@4ax.com>
NNTP-Posting-Host: 10.22.241.41
X-Original-NNTP-Posting-Host: 10.22.241.41
Date: 29 Nov 2010 13:40:48 -0800
X-Trace: forums-1-dub 1291066848 10.22.241.41 (29 Nov 2010 13:40:48 -0800)
X-Original-Trace: 29 Nov 2010 13:40:48 -0800, 10.22.241.41
Lines: 62
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:29740
Article PK: 78967

some stupid thoughts...

If there was no performance issue after creating 5 DB's
(other than you seeing 100% cpu), that probably would
indicate increase in throughput. More clients are processing
and doing work which might otherwise be stalled(briefly) in
your old setup. A good comparison would be the logical io's
in both the setup(old and new). Any movement of objects in
cache from LRU to MRU in strict config probably will use CPU
cycles ( Guess you had one single default data cache).

Even after reverting back application configuration to
connect to 1 DB, you still saw performance issue. Maybe the
objects were still in default data cache and shuffled around
in cache itself(LRU MRU movement and re-creating the
chains). A good test would have been to have all 5 database
bind to its own cache and avoid using default data cache.

When you created 5 DB's did you dump and load the same
database? In such case the object id's will be same. Would
this cause the ASE alogrithm to do unnecessary weeding
before it can locate the right object id! Not sure.

> I need some help with explaining the following:
>
> We have a database used by the application as a temp
> working/storage by the app (extreme transaction activity).
> Because we have so many users hitting the same temp
> working/storage db, we have log semaphore contention. So,
> we implemented a design to break up the one temp
> working/storage db into 5 to get better throughput. 1/5th
> the users would go to a separate db with it's own
> logsegment. This involved creating 5 dbs with its own
> views, procs. Around 1000 procs and 200 views in each.
> We scaled the config params to account. But upon
> implmentation, engine busy % went to 100% starting at 8am
> and continuing. After reviewing MDA data, I am convinced
> there was no code causing the 100% cpu. Nothing in
> sp_monitorconfig showed any reuse. No bad query plans,
> etc. No cpu intensive loops,etc. We had to roll back to
> using the same one temp working/storage db. After rolling
> back the app, cpu usage was still 100%. I had to actually
> drop all the procs/views in the 5 dbs (which were not
> being used after rollback) and after that, we returned to
> normal. These procs/views were still in cache from before
> we rolled back the app. But after we rolled back, engine
> cpu utilitzation still at 100%. After dropping all the
> procs/views from the extra dbs (which were no longer being
> used), cpu went back down to normal.
>
> I am extremely perplexed.
>
> Any thoughts on explaining this?
>
> version is:
> Adaptive Server Enterprise/15.0.3/EBF 17273 ESD#2
> ONE-OFF/P/RS6000/AIX 5.3/ase1503/2708/64-bit/FBO/Wed Oct
> 14 11:17:45 2009
>
>
> Bob