What kind of disk subsystem is your database on? Faster the better. But
also make sure your transaction log is on a completely separate set of
physical disks than your data file. That way they won't contend for the
same resources. If possible, keep the paging file and the OS on their
own dedicated disk(s) too.

 

And what RAID configuration are you using? 

 

Chad Hall  
(501) 342-2650

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Craig Carter
Sent: Tuesday, June 24, 2008 8:29 AM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Server huge translogs and very poor performance

 

This may be obvious but you didn't specify what version of SQL, etc.  At
a minimum, you do have daily transaction log backups running right?
Unless you back up the logs on a regular basis (at least daily), they
will continue to grow and degrade performance.  Since you don't get
backups by default when you create a database, it is easy to overlook.

 

Second; we found one of our servers was set up with a very restrictive
and fixed Virtual Memory setting (paging file).  You may want to check
that and increase it if needed.

 

Since your servers are only 4GB, AWE memory allocation shouldn't be a
factor.  When you are running more than 4GB, turning that on helps a
lot.

 

If you have regular transaction log backups, the recommendation below
makes a lot of sense since you need to try and determine what is causing
the rapid growth.

 

Craig Carter

Software Engineer, RSP

 

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing
Sent: Monday, June 23, 2008 5:31 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Server huge translogs and very poor performance

 

About the only tip I can give you is this.  Give yourself enough room
for your transaction logs.  They are growing for a reason...you could
try turning on sql logging to see what your server is busy doing because
the logs shouldn't be growing if your app isn't doing anything.  Your
DBA should be able to tell you who is connected to the db, and your sql
logs should be able to tell you who is making modifications to what
values.

 

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Gillock
Sent: Monday, June 23, 2008 5:23 PM
To: arslist@ARSLIST.ORG
Subject: SQL Server huge translogs and very poor performance

** 

Hey Listers,

                Does anyone have any tips for maintaining transaction
logs in SQL Server?  Ours seem to growing at an insane rate and nothing
our DBAs are doing is helping at all.  And I'm continually getting time
outs when trying to save workflow.  And that is without any users.
There is nothing special setup in development and I can do a backup,
truncating the logs and that helps for a while.  In production, however,
we have log mirroring setup for DR purposes.  It's killing me.  The DB
and AR box are both on their own dual quad core servers with 4GB RAM, so
I don't think it's a resource issue.  Any advice is appreciated.

 

Thanks!

Brian

 

 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers Are" html___
***************************************************************************
The information contained in this communication is confidential, is
intended only for the use of the recipient named above, and may be legally
privileged.

If the reader of this message is not the intended recipient, you are
hereby notified that any dissemination, distribution or copying of this
communication is strictly prohibited.

If you have received this communication in error, please resend this
communication to the sender and delete the original message or any copy
of it from your computer system.

Thank You.
****************************************************************************

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to