Showing posts with label runaway. Show all posts
Showing posts with label runaway. Show all posts

Friday, March 23, 2012

Runaway log files

Hello,

I am administering a DB which is about 2GB in size and sees few hundred,
maybe up to a few thousand inserts a day plus very few deletions and updates
(less than few hundred). DB has about 200,000 records in it total. For some
time now I have noticed that the transaction logs grow a lot -- like 1GB per
day. I don't know why they are growing so much and would like to find out
why - DB usage that I know of cannot cause such a high growth, to my best
knowledge.

Is there a way to find out what is causing such growth? Can I examine these
logs somehow and see what is in them? I am worried that somehow someone
managed to run mass updates on the DB without my knowledge.

Thanks for help,

Tom Kitta"Tom Kitta" <tom@.energyshop.com> wrote in message
news:D527b.28080$mk1.4594@.news02.bloor.is.net.cabl e.rogers.com...
> Hello,
> I am administering a DB which is about 2GB in size and sees few hundred,
> maybe up to a few thousand inserts a day plus very few deletions and
updates
> (less than few hundred). DB has about 200,000 records in it total. For
some
> time now I have noticed that the transaction logs grow a lot -- like 1GB
per
> day. I don't know why they are growing so much and would like to find out
> why - DB usage that I know of cannot cause such a high growth, to my best
> knowledge.
> Is there a way to find out what is causing such growth? Can I examine
these
> logs somehow and see what is in them? I am worried that somehow someone
> managed to run mass updates on the DB without my knowledge.
> Thanks for help,
> Tom Kitta

Do you mean that your log is growing continuously? That may be normal,
depending on your backup strategy - if you're in Full recovery mode, but
never back up the log, for example. If that's the case, you can look at
backing up the log regularly or changing to Simple recovery mode.

If you're doing that already, and you mean that the log grows more over a
day than you expect, then one possibility is to use Profiler to trace the
"Log File Auto Grow" event, and look for other events before it in the trace
output. If there are one or two queries that require lots of log space, you
should be able to identify them.

Simon

Runaway Log Files

Our production server ran out of disk space over the weekend due to a
runaway log file condition (again).
We had this happen about 2 months ago, prior to SP1, and I reported it here.
MS admitted that had seen the problem, but was not able to reproduce.
In the Event Log, I see thousands of entries like:
Event Type: Warning
Event Source: Schedule and Delivery Processor
Event Category: Logging
Event ID: 123
Date: 8/30/2004
Time: 11:55:16 AM
User: N/A
Computer: KYLE
Description:
The report server failed to write to the trace log.
In the log files, about 8 megabytes in size each until 10 gigabyte disk
capacity was reached, contains repeated entries as follows:
ReportingServicesService!dbcleanup!1308!8/30/2004-11:55:16:: i INFO: Cleaned
0 broken snapshots, 0 chunks
ReportingServicesService!runningjobs!1308!8/30/2004-11:55:16:: i INFO:
Execution Log Entry Expiration timer enabled: Cycle: 50683 seconds
ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO: Expiring
old execution log entries
ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO:
Expiration of old execution log entries is complete. Removed 0 entries.
I was hoping this was fixed in SP1, which we are running now. Any ideas?
thx
JeffI already replied to your other post, but will duplicate info here. We have
found the bug and you should contact PSS for a fix to the issue.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:OYofuMsjEHA.2948@.TK2MSFTNGP11.phx.gbl...
> Our production server ran out of disk space over the weekend due to a
> runaway log file condition (again).
> We had this happen about 2 months ago, prior to SP1, and I reported it
here.
> MS admitted that had seen the problem, but was not able to reproduce.
> In the Event Log, I see thousands of entries like:
> Event Type: Warning
> Event Source: Schedule and Delivery Processor
> Event Category: Logging
> Event ID: 123
> Date: 8/30/2004
> Time: 11:55:16 AM
> User: N/A
> Computer: KYLE
> Description:
> The report server failed to write to the trace log.
> In the log files, about 8 megabytes in size each until 10 gigabyte disk
> capacity was reached, contains repeated entries as follows:
> ReportingServicesService!dbcleanup!1308!8/30/2004-11:55:16:: i INFO:
Cleaned
> 0 broken snapshots, 0 chunks
> ReportingServicesService!runningjobs!1308!8/30/2004-11:55:16:: i INFO:
> Execution Log Entry Expiration timer enabled: Cycle: 50683 seconds
> ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO:
Expiring
> old execution log entries
> ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO:
> Expiration of old execution log entries is complete. Removed 0 entries.
> I was hoping this was fixed in SP1, which we are running now. Any ideas?
> thx
> Jeff
>

Runaway log files

Some of you have run into a problem with the log files being written to and
consuming the entire hard drive. We have identified the issue and have
provided a fix. The KB article itself has not yet been published but the
fix is available through PSS. Please feel free to contact PSS and refer
them to KB 885286.
For everyone who has been waiting for this, thank you for your patience.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.Hi,
When will this fix be available for download?
Erik
"Daniel Reib [MSFT]" <danreib@.online.microsoft.com> wrote in message
news:OSFl%23KPnEHA.3076@.TK2MSFTNGP15.phx.gbl...
> Some of you have run into a problem with the log files being written to
and
> consuming the entire hard drive. We have identified the issue and have
> provided a fix. The KB article itself has not yet been published but the
> fix is available through PSS. Please feel free to contact PSS and refer
> them to KB 885286.
> For everyone who has been waiting for this, thank you for your patience.
> --
> -Daniel
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>|||This has become a critical issue for the company I work
for.
A fix is needed pronto. Is this a matter of days for the
fix or "Future Thinking"?
>--Original Message--
>Hi,
>When will this fix be available for download?
>Erik
>"Daniel Reib [MSFT]" <danreib@.online.microsoft.com>
wrote in message
>news:OSFl%23KPnEHA.3076@.TK2MSFTNGP15.phx.gbl...
>> Some of you have run into a problem with the log files
being written to
>and
>> consuming the entire hard drive. We have identified
the issue and have
>> provided a fix. The KB article itself has not yet
been published but the
>> fix is available through PSS. Please feel free to
contact PSS and refer
>> them to KB 885286.
>> For everyone who has been waiting for this, thank you
for your patience.
>> --
>> -Daniel
>> This posting is provided "AS IS" with no warranties,
and confers no
>rights.
>>
>
>.
>|||At this point the fix is only available through PSS.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Erik Tamminga" <REVERSE_THIS_agnimmate@.REVERSE_THIS_nerrats.ln> wrote in
message news:eqTrhhvnEHA.2096@.TK2MSFTNGP15.phx.gbl...
> Hi,
> When will this fix be available for download?
> Erik
> "Daniel Reib [MSFT]" <danreib@.online.microsoft.com> wrote in message
> news:OSFl%23KPnEHA.3076@.TK2MSFTNGP15.phx.gbl...
> > Some of you have run into a problem with the log files being written to
> and
> > consuming the entire hard drive. We have identified the issue and have
> > provided a fix. The KB article itself has not yet been published but
the
> > fix is available through PSS. Please feel free to contact PSS and refer
> > them to KB 885286.
> >
> > For everyone who has been waiting for this, thank you for your patience.
> >
> > --
> > -Daniel
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> >
> >
>|||The fix is available now. You will need to contact PSS and reference the KB
number below. The fix is currently not available as a public download.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dave Laskey" <anonymous@.discussions.microsoft.com> wrote in message
news:0ec501c49f2b$26f188b0$3501280a@.phx.gbl...
> This has become a critical issue for the company I work
> for.
> A fix is needed pronto. Is this a matter of days for the
> fix or "Future Thinking"?
> >--Original Message--
> >Hi,
> >
> >When will this fix be available for download?
> >
> >Erik
> >
> >"Daniel Reib [MSFT]" <danreib@.online.microsoft.com>
> wrote in message
> >news:OSFl%23KPnEHA.3076@.TK2MSFTNGP15.phx.gbl...
> >> Some of you have run into a problem with the log files
> being written to
> >and
> >> consuming the entire hard drive. We have identified
> the issue and have
> >> provided a fix. The KB article itself has not yet
> been published but the
> >> fix is available through PSS. Please feel free to
> contact PSS and refer
> >> them to KB 885286.
> >>
> >> For everyone who has been waiting for this, thank you
> for your patience.
> >>
> >> --
> >> -Daniel
> >> This posting is provided "AS IS" with no warranties,
> and confers no
> >rights.
> >>
> >>
> >>
> >
> >
> >.
> >

runaway jobs

Hi,
Some of my developers have scheduled jobs which run for hours...how can i get an alert on job that have been running for more than 30 minutes.Use SP_HELP_JOB repeatedly to get the execution status.

Also make sure to identify why those jobs are taking too long to return the status/completion.|||msdb..sysjobhistory tables has fields that could help you:

run_status (int) - Status of the job execution:
0 = Failed
1 = Succeeded
2 = Retry
3 = Canceled
4 = In progress

run_date (int) - Date the job or step started execution. For an In Progress history, this is the date/time the history was written.|||MS discourages querying directly SYSTEM tables, I believe SP_HELP_JOB does give same information.|||knock the developers heads together ? maybe then they will be a bit more thoughtfull about the performace of their jobs ...|||NetIQ has a piece of software called DiagnosticsManager for SQL that will monitor problem queries.|||Hi I am writing a script to check quickly jobs which failed or running endlessly.

I am checking the sysjobhistory run_status field

run_status (int) - Status of the job execution:
0 = Failed
1 = Succeeded
2 = Retry
3 = Canceled
4 = In progress

After lots of tests, I never saw status 4 when a job is running so I cannot perform my task correctly...|||Originally posted by Satya
MS discourages querying directly SYSTEM tables, I believe SP_HELP_JOB does give same information.

Wierd !!!

I did not get this one ...Running this much code instead of one single query is recommended by MS

CREATE PROCEDURE sp_help_job
-- Individual job parameters
@.job_id UNIQUEIDENTIFIER = NULL, -- If provided should NOT also provide job_name
@.job_name sysname = NULL, -- If provided should NOT also provide job_id
@.job_aspect VARCHAR(9) = NULL, -- JOB, STEPS, SCEDULES, TARGETS or ALL
-- Job set parameters
@.job_type VARCHAR(12) = NULL, -- LOCAL or MULTI-SERVER
@.owner_login_name sysname = NULL,
@.subsystem NVARCHAR(40) = NULL,
@.category_name sysname = NULL,
@.enabled TINYINT = NULL,
@.execution_status INT = NULL, -- 1 = Executing, 2 = Waiting For Thread, 3 = Between Retries, 4 = Idle, 5 = Suspended, 6 = [obsolete], 7 = PerformingCompletionActions
@.date_comparator CHAR(1) = NULL, -- >, < or =
@.date_created DATETIME = NULL,
@.date_last_modified DATETIME = NULL,
@.description NVARCHAR(512) = NULL -- We do a LIKE on this so it can include wildcards
AS
BEGIN
DECLARE @.retval INT
DECLARE @.category_id INT
DECLARE @.job_id_as_char VARCHAR(36)
DECLARE @.res_valid_range NVARCHAR(200)

SET NOCOUNT ON

-- Remove any leading/trailing spaces from parameters (except @.owner_login_name)
SELECT @.job_name = LTRIM(RTRIM(@.job_name))
SELECT @.job_aspect = LTRIM(RTRIM(@.job_aspect))
SELECT @.job_type = LTRIM(RTRIM(@.job_type))
SELECT @.subsystem = LTRIM(RTRIM(@.subsystem))
SELECT @.category_name = LTRIM(RTRIM(@.category_name))
SELECT @.description = LTRIM(RTRIM(@.description))

-- Turn [nullable] empty string parameters into NULLs
IF (@.job_name = N'') SELECT @.job_name = NULL
IF (@.job_aspect = '') SELECT @.job_aspect = NULL
IF (@.job_type = '') SELECT @.job_type = NULL
IF (@.owner_login_name = N'') SELECT @.owner_login_name = NULL
IF (@.subsystem = N'') SELECT @.subsystem = NULL
IF (@.category_name = N'') SELECT @.category_name = NULL
IF (@.description = N'') SELECT @.description = NULL

IF ((@.job_id IS NOT NULL) OR (@.job_name IS NOT NULL))
BEGIN
EXECUTE @.retval = sp_verify_job_identifiers '@.job_name',
'@.job_id',
@.job_name OUTPUT,
@.job_id OUTPUT
IF (@.retval <> 0)
RETURN(1) -- Failure
END

SELECT @.job_id_as_char = CONVERT(VARCHAR(36), @.job_id)

-- If the user provided a job name or id but no aspect, default to ALL
IF ((@.job_name IS NOT NULL) OR (@.job_id IS NOT NULL)) AND (@.job_aspect IS NULL)
SELECT @.job_aspect = 'ALL'

-- The caller must supply EITHER job name (or job id) and aspect OR one-or-more of the set
-- parameters OR no parameters at all
IF (((@.job_name IS NOT NULL) OR (@.job_id IS NOT NULL))
AND ((@.job_aspect IS NULL) OR
(@.job_type IS NOT NULL) OR
(@.owner_login_name IS NOT NULL) OR
(@.subsystem IS NOT NULL) OR
(@.category_name IS NOT NULL) OR
(@.enabled IS NOT NULL) OR
(@.date_comparator IS NOT NULL) OR
(@.date_created IS NOT NULL) OR
(@.date_last_modified IS NOT NULL)))
OR
((@.job_name IS NULL) AND (@.job_id IS NULL) AND (@.job_aspect IS NOT NULL))
BEGIN
RAISERROR(14280, -1, -1)
RETURN(1) -- Failure
END

IF (@.job_id IS NOT NULL)
BEGIN
-- Individual job...

-- Check job aspect
SELECT @.job_aspect = UPPER(@.job_aspect)
IF (@.job_aspect NOT IN ('JOB', 'STEPS', 'SCHEDULES', 'TARGETS', 'ALL'))
BEGIN
RAISERROR(14266, -1, -1, '@.job_aspect', 'JOB, STEPS, SCHEDULES, TARGETS, ALL')
RETURN(1) -- Failure
END

-- Generate results set...

IF (@.job_aspect IN ('JOB', 'ALL'))
BEGIN
IF (@.job_aspect = 'ALL')
BEGIN
RAISERROR(14213, 0, 1)
PRINT REPLICATE('=', DATALENGTH(FORMATMESSAGE(14213)) / 2)
END
EXECUTE sp_get_composite_job_info @.job_id,
@.job_type,
@.owner_login_name,
@.subsystem,
@.category_id,
@.enabled,
@.execution_status,
@.date_comparator,
@.date_created,
@.date_last_modified,
@.description
END

IF (@.job_aspect IN ('STEPS', 'ALL'))
BEGIN
IF (@.job_aspect = 'ALL')
BEGIN
PRINT ''
RAISERROR(14214, 0, 1)
PRINT REPLICATE('=', DATALENGTH(FORMATMESSAGE(14214)) / 2)
END
EXECUTE ('EXECUTE sp_help_jobstep @.job_id = ''' + @.job_id_as_char + ''', @.suffix = 1')
END

IF (@.job_aspect IN ('SCHEDULES', 'ALL'))
BEGIN
IF (@.job_aspect = 'ALL')
BEGIN
PRINT ''
RAISERROR(14215, 0, 1)
PRINT REPLICATE('=', DATALENGTH(FORMATMESSAGE(14215)) / 2)
END
EXECUTE ('EXECUTE sp_help_jobschedule @.job_id = ''' + @.job_id_as_char + '''')
END

IF (@.job_aspect IN ('TARGETS', 'ALL'))
BEGIN
IF (@.job_aspect = 'ALL')
BEGIN
PRINT ''
RAISERROR(14216, 0, 1)
PRINT REPLICATE('=', DATALENGTH(FORMATMESSAGE(14216)) / 2)
END
EXECUTE ('EXECUTE sp_help_jobserver @.job_id = ''' + @.job_id_as_char + ''', @.show_last_run_details = 1')
END
END
ELSE
BEGIN
-- Set of jobs...

-- Check job type
IF (@.job_type IS NOT NULL)
BEGIN
SELECT @.job_type = UPPER(@.job_type)
IF (@.job_type NOT IN ('LOCAL', 'MULTI-SERVER'))
BEGIN
RAISERROR(14266, -1, -1, '@.job_type', 'LOCAL, MULTI-SERVER')
RETURN(1) -- Failure
END
END

-- Check owner
IF (@.owner_login_name IS NOT NULL)
BEGIN
IF (SUSER_SID(@.owner_login_name) IS NULL)
BEGIN
RAISERROR(14262, -1, -1, '@.owner_login_name', @.owner_login_name)
RETURN(1) -- Failure
END
END

-- Check subsystem
IF (@.subsystem IS NOT NULL)
BEGIN
EXECUTE @.retval = sp_verify_subsystem @.subsystem
IF (@.retval <> 0)
RETURN(1) -- Failure
END

-- Check job category
IF (@.category_name IS NOT NULL)
BEGIN
SELECT @.category_id = category_id
FROM msdb.dbo.syscategories
WHERE (category_class = 1) -- Job
AND (name = @.category_name)
IF (@.category_id IS NULL)
BEGIN
RAISERROR(14262, -1, -1, '@.category_name', @.category_name)
RETURN(1) -- Failure
END
END

-- Check enabled state
IF (@.enabled IS NOT NULL) AND (@.enabled NOT IN (0, 1))
BEGIN
RAISERROR(14266, -1, -1, '@.enabled', '0, 1')
RETURN(1) -- Failure
END

-- Check current execution status
IF (@.execution_status IS NOT NULL)
BEGIN
IF (@.execution_status NOT IN (0, 1, 2, 3, 4, 5, 7))
BEGIN
SELECT @.res_valid_range = FORMATMESSAGE(14204)
RAISERROR(14266, -1, -1, '@.execution_status', @.res_valid_range)
RETURN(1) -- Failure
END
END

-- If a date comparator is supplied, we must have either a date-created or date-last-modified
IF ((@.date_comparator IS NOT NULL) AND (@.date_created IS NOT NULL) AND (@.date_last_modified IS NOT NULL)) OR
((@.date_comparator IS NULL) AND ((@.date_created IS NOT NULL) OR (@.date_last_modified IS NOT NULL)))
BEGIN
RAISERROR(14282, -1, -1)
RETURN(1) -- Failure
END

-- Check dates / comparator
IF (@.date_comparator IS NOT NULL) AND (@.date_comparator NOT IN ('=', '<', '>'))
BEGIN
RAISERROR(14266, -1, -1, '@.date_comparator', '=, >, <')
RETURN(1) -- Failure
END
IF (@.date_created IS NOT NULL) AND
((@.date_created < '1 Jan 1990 12:00:00am') OR (@.date_created > '31 Dec 9999 11:59:59pm'))
BEGIN
RAISERROR(14266, -1, -1, '@.date_created', '1/1/1990 12:00am .. 12/31/9999 11:59pm')
RETURN(1) -- Failure
END
IF (@.date_last_modified IS NOT NULL) AND
((@.date_last_modified < '1 Jan 1990 12:00am') OR (@.date_last_modified > 'Dec 31 9999 11:59:59pm'))
BEGIN
RAISERROR(14266, -1, -1, '@.date_last_modified', '1/1/1990 12:00am .. 12/31/9999 11:59pm')
RETURN(1) -- Failure
END

-- Generate results set...
EXECUTE sp_get_composite_job_info @.job_id,
@.job_type,
@.owner_login_name,
@.subsystem,
@.category_id,
@.enabled,
@.execution_status,
@.date_comparator,
@.date_created,
@.date_last_modified,
@.description
END

RETURN(0) -- Success
END|||Hi !

In effect this store proc returns the fields I need but I wonder how can I perform a select from the result of this store proc ?

Shourl I redirect the result of the stored proc to a temporary table and if yes what is the redirection instruction ?

Could you help please ?|||INSERT INTO myTable99 EXEC sp_whatever..

my favorite line of MS code is in sp_help

-- IF NOT IN SYSOBJECTS, TRY SYSTYPES --
if @.objid is null
begin
-- UNDONE: SHOULD CHECK FOR AND DISALLOW MULTI-PART NAME
select @.objid = xusertype from systypes where name = @.objname

-- IF NOT IN SYSTYPES, GIVE UP
if @.objid is null
begin
select @.dbname=db_name()
raiserror(15009,-1,-1,@.objname,@.dbname)
return(1)
end|||Thanks ! I have all I need to check jobs still running !|||.. More or less :-(

insert into ##sp_help_job_table exec sp_help_job

Server: Msg 8164, Level 16, State 1, Procedure sp_get_composite_job_info, Line 67
An INSERT EXEC statement cannot be nested.|||Originally posted by Satya
MS discourages querying directly SYSTEM tables, I believe SP_HELP_JOB does give same information.

Since u said that, I was wondering why its discouraged? thx|||I am also discouraged of using system store procs...
No issue to my problem...|||"MS discourages querying directly SYSTEM tables, I believe SP_HELP_JOB does give same information."

Screw M$.

If they had their way we'd all be using wizards and nobody would have a clue what was going on in the background. "Pay no attention to the little man behind the curtain!"

Reference the system tables and you'll learn something about how Microsoft works. If a newly released version requires you to change your code, then learn how the new system works. I don't think that's a bad thing.

blindman|||ok...I can't find sp_help_job...where does it live?

never mind

I thought it was because you couldn't use temp tables with an EXEC...

but

CREATE TABLE wrk_sp_help_Job(
job_id varchar(255)
, job_name sysname
, job_aspect VARCHAR(9)
, job_type VARCHAR(12)
, owner_login_name sysname
, subsystem NVARCHAR(40)
, category_name sysname
, enabled TINYINT
, execution_status INT
, date_comparator CHAR(1)
, date_created DATETIME
, date_last_modified DATETIME
, [description] NVARCHAR(512)
)
GO

INSERT INTO wrk_sp_help_job EXEC msdb..sp_help_job

DROP TABLE wrk_sp_help_job

oesn't work either...it seems like since the sproc is calling other sprocs (nested) that it won't work...

gotta be a way...|||I remember looking into this little rat-hole before. I got as far as an extended stored procedure called xp_sqlagent_enum_jobs. The current run status is returned by this procedure, but you have to supply two parameters (at least on SP3). So the full syntax is:

master.dbo.xp_sqlagent_enum_jobs 1, 'sa'

This returns all of the jobs on my test server, but I do not have anything owned by regular users. I always yank the guest user out of MSDB, before letting any of the masses on to the box ;-).

Brett, you should be able to drop this into a temp table, then join that temp table back to sysjobs for readable names and the like.|||Wow...it's a dll

and it store the dates and times separately as char data...

You go M$, you go...

maybe I can sell donughts...sql

Runaway CPU

For some reason, for two days now, in the morning hours
the sqlservr.exe process is using an average of 94% of the
CPU on a very powerful server.
Can anyone tell me how to determine what the problem is,
without just rebooting the server?
Here are some Buffer Manager statistics in case it helps:
Buffer cache hit ratio 3044
Buffer cache hit ratio base 3048
Page lookups/sec 405446548
Free list stalls/sec 114
Free pages 291
Total pages 207872
Target pages 207872
Database pages 190592
Reserved pages 648
Stolen pages 16989
Lazy writes/sec 1722
Readahead pages/sec 477294
Procedure cache pages 14862
Page reads/sec 616224
Page writes/sec 658045
Checkpoint pages/sec 315881
Thanks.
Allen"Allen White" <awhite_nospam@.advanstar.com> wrote in message
news:21b501c4d885$f31e0f60$a501280a@.phx.gbl...
> For some reason, for two days now, in the morning hours
> the sqlservr.exe process is using an average of 94% of the
> CPU on a very powerful server.
> Can anyone tell me how to determine what the problem is,
> without just rebooting the server?
> Here are some Buffer Manager statistics in case it helps:
> Buffer cache hit ratio 3044
> Buffer cache hit ratio base 3048
> Page lookups/sec 405446548
> Free list stalls/sec 114
> Free pages 291
> Total pages 207872
> Target pages 207872
> Database pages 190592
> Reserved pages 648
> Stolen pages 16989
> Lazy writes/sec 1722
> Readahead pages/sec 477294
> Procedure cache pages 14862
> Page reads/sec 616224
> Page writes/sec 658045
> Checkpoint pages/sec 315881
> Thanks.
> Allen
>
Turn on Profiler..
What jobs (if any) are running? Do you have maintenance plans executing
that are rebuilding indexes?
Rick Sawtell
MCT, MCSD, MCDBA|||Thanks, Rick. No maintenance plans are running. I keep a
trace running on all my production servers and have
reviewed the trace files and can see nothing that would
cause that kind of CPU activity. (The trace captures just
Batch Complete and RPC Complete activity.) I see lots and
lots of transactions, but nothing running for long periods
of time, nor anything that would be processor intensive.
Allen
>--Original Message--
>"Allen White" <awhite_nospam@.advanstar.com> wrote in
message
>news:21b501c4d885$f31e0f60$a501280a@.phx.gbl...
>> For some reason, for two days now, in the morning hours
>> the sqlservr.exe process is using an average of 94% of
the
>> CPU on a very powerful server.
>> Can anyone tell me how to determine what the problem is,
>> without just rebooting the server?
>> Here are some Buffer Manager statistics in case it
helps:
>> Buffer cache hit ratio 3044
>> Buffer cache hit ratio base 3048
>> Page lookups/sec 405446548
>> Free list stalls/sec 114
>> Free pages 291
>> Total pages 207872
>> Target pages 207872
>> Database pages 190592
>> Reserved pages 648
>> Stolen pages 16989
>> Lazy writes/sec 1722
>> Readahead pages/sec 477294
>> Procedure cache pages 14862
>> Page reads/sec 616224
>> Page writes/sec 658045
>> Checkpoint pages/sec 315881
>> Thanks.
>> Allen
>Turn on Profiler..
>What jobs (if any) are running? Do you have maintenance
plans executing
>that are rebuilding indexes?
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
>

Runaway CPU

For some reason, for two days now, in the morning hours
the sqlservr.exe process is using an average of 94% of the
CPU on a very powerful server.
Can anyone tell me how to determine what the problem is,
without just rebooting the server?
Here are some Buffer Manager statistics in case it helps:
Buffer cache hit ratio3044
Buffer cache hit ratio base3048
Page lookups/sec405446548
Free list stalls/sec114
Free pages291
Total pages207872
Target pages207872
Database pages190592
Reserved pages648
Stolen pages16989
Lazy writes/sec1722
Readahead pages/sec477294
Procedure cache pages14862
Page reads/sec616224
Page writes/sec658045
Checkpoint pages/sec315881
Thanks.
Allen
"Allen White" <awhite_nospam@.advanstar.com> wrote in message
news:21b501c4d885$f31e0f60$a501280a@.phx.gbl...
> For some reason, for two days now, in the morning hours
> the sqlservr.exe process is using an average of 94% of the
> CPU on a very powerful server.
> Can anyone tell me how to determine what the problem is,
> without just rebooting the server?
> Here are some Buffer Manager statistics in case it helps:
> Buffer cache hit ratio 3044
> Buffer cache hit ratio base 3048
> Page lookups/sec 405446548
> Free list stalls/sec 114
> Free pages 291
> Total pages 207872
> Target pages 207872
> Database pages 190592
> Reserved pages 648
> Stolen pages 16989
> Lazy writes/sec 1722
> Readahead pages/sec 477294
> Procedure cache pages 14862
> Page reads/sec 616224
> Page writes/sec 658045
> Checkpoint pages/sec 315881
> Thanks.
> Allen
>
Turn on Profiler..
What jobs (if any) are running? Do you have maintenance plans executing
that are rebuilding indexes?
Rick Sawtell
MCT, MCSD, MCDBA
|||Thanks, Rick. No maintenance plans are running. I keep a
trace running on all my production servers and have
reviewed the trace files and can see nothing that would
cause that kind of CPU activity. (The trace captures just
Batch Complete and RPC Complete activity.) I see lots and
lots of transactions, but nothing running for long periods
of time, nor anything that would be processor intensive.
Allen

>--Original Message--
>"Allen White" <awhite_nospam@.advanstar.com> wrote in
message[vbcol=seagreen]
>news:21b501c4d885$f31e0f60$a501280a@.phx.gbl...
the[vbcol=seagreen]
helps:
>Turn on Profiler..
>What jobs (if any) are running? Do you have maintenance
plans executing
>that are rebuilding indexes?
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
>

Runaway CPU

For some reason, for two days now, in the morning hours
the sqlservr.exe process is using an average of 94% of the
CPU on a very powerful server.
Can anyone tell me how to determine what the problem is,
without just rebooting the server?
Here are some Buffer Manager statistics in case it helps:
Buffer cache hit ratio 3044
Buffer cache hit ratio base 3048
Page lookups/sec 405446548
Free list stalls/sec 114
Free pages 291
Total pages 207872
Target pages 207872
Database pages 190592
Reserved pages 648
Stolen pages 16989
Lazy writes/sec 1722
Readahead pages/sec 477294
Procedure cache pages 14862
Page reads/sec 616224
Page writes/sec 658045
Checkpoint pages/sec 315881
Thanks.
Allen"Allen White" <awhite_nospam@.advanstar.com> wrote in message
news:21b501c4d885$f31e0f60$a501280a@.phx.gbl...
> For some reason, for two days now, in the morning hours
> the sqlservr.exe process is using an average of 94% of the
> CPU on a very powerful server.
> Can anyone tell me how to determine what the problem is,
> without just rebooting the server?
> Here are some Buffer Manager statistics in case it helps:
> Buffer cache hit ratio 3044
> Buffer cache hit ratio base 3048
> Page lookups/sec 405446548
> Free list stalls/sec 114
> Free pages 291
> Total pages 207872
> Target pages 207872
> Database pages 190592
> Reserved pages 648
> Stolen pages 16989
> Lazy writes/sec 1722
> Readahead pages/sec 477294
> Procedure cache pages 14862
> Page reads/sec 616224
> Page writes/sec 658045
> Checkpoint pages/sec 315881
> Thanks.
> Allen
>
Turn on Profiler..
What jobs (if any) are running? Do you have maintenance plans executing
that are rebuilding indexes?
Rick Sawtell
MCT, MCSD, MCDBA|||Thanks, Rick. No maintenance plans are running. I keep a
trace running on all my production servers and have
reviewed the trace files and can see nothing that would
cause that kind of CPU activity. (The trace captures just
Batch Complete and RPC Complete activity.) I see lots and
lots of transactions, but nothing running for long periods
of time, nor anything that would be processor intensive.
Allen

>--Original Message--
>"Allen White" <awhite_nospam@.advanstar.com> wrote in
message
>news:21b501c4d885$f31e0f60$a501280a@.phx.gbl...
the[vbcol=seagreen]
helps:[vbcol=seagreen]
>Turn on Profiler..
>What jobs (if any) are running? Do you have maintenance
plans executing
>that are rebuilding indexes?
>Rick Sawtell
>MCT, MCSD, MCDBA
>
>.
>