This same solution worked for me as well!

Ran repair for shared features and then reran the SP upgrade.

Thanks!

We ended up rewriting the queries involved....one of the stored procs had group by in the orderby clause..this was the culprit....after the rewrite...we had no issues.

Hope this helps.

Can you explain how to add the recompile hint for this procedure?

Thx..I will read the guide today...I didnt write this SP....got handed to me...so I am pressed with finding out whey now it performs bad as we added the additional memory...

But why would it do that with the extra memory? Is there a way around this?

Its almost as if I shouldnt have added the additional memory.......

Here is the proc:

...

Ok I compared the 2 execution plans....

one execution plan from when the max server memory was 26 gig and one from when the max server memory was set to 54...

partitions on raid array...

However, in the month I will be moving my data to our san system. I will create one volume for each lun I create; so this...

6 disks make up the RAID 5.

data and logs are split onto separte drives; tempdb on its own drive.

server is dl380 with 15k rpm drives...

raid 5 set.

ITs an off the shelf product.

This particular select statement is being generated by the SUN app and its done when they run a ledger update.

doesnt appear to really have helped....attached is the new sqlplan.

also my indexes do NOT have much fragmentation..I do a reorg every other day and rebuild once a week.

Thanks!

Here it is.

FULL TABLE DEFINITIONS INCLUDE:

TABLE:

CREATE TABLE [dbo].[BD1_STD_TEXT_LDG](

[ACCNT_CODE] [dbo].[REF_MAINT_CODE] NOT NULL,

[PERIOD] [dbo].[FIN_PERD_INT] NOT NULL,

[TRANS_DATETIME] [dbo].[FIN_DATETIME] NOT NULL,

[JRNAL_NO] [dbo].[FIN_JNL_NUM] NOT NULL,

[JRNAL_LINE] [dbo].[FIN_JNL_LINE] NOT NULL,

[STD_TEXT_CLASS_CODE] [dbo].[REF_MAINT_CODE] NOT NULL,

[STD_TEXT_CODE] [dbo].[REF_MAINT_CODE] NOT NULL,

[UPDATE_COUNT] [dbo].[UPDATE_CNT] NOT NULL,

[LAST_CHANGE_USER_ID]...