Abnormal Timeout Issue on Production System

Hi all,
My production system is experiencing abnormal timeouts during posting of
transaction. The abnormal part is:
System usually works fine for about 6 ws; but one unlucky day, suddenly
for no apparent reason, system experiences massive timeout for about 2 - 3
hours; after that everything is fine again.
A background on the production system:
? It is a sales and stock control system. With a fair number (nothing
massive) of sales transactions every operation days
? Approx 50 client users
? Developed using VB .Net, VS 2003
? Running on .Net Framework 2.0
? Running on SQL Server database
? Supports multi-user, single database
It is also running on a pretty high-end server (from what I was told) with
spec:
? HP ML 530 G2 machine
? 2-processors, each 3 GHz, running Xeon HT
? 4 GB ECC RAM
? HDD running RAID 0 and RAID 1; Total disk space 200 GB, with 72 GB free
? SQL Server 2003 standard edition with sp3
? Windows 2003 Server standard edition
? Running other s/w, mainly Norton Anti-Virus 9.0 corp. version and Verita
s
9.1
USUALLY DURING THE FINE DAYS…
System works fine during both peak and off-peak hours with very rare
timeouts. Those timeouts are caused mainly by updating of "constant" tables,
such as stock when two customers are buying the same item at the same time.
That is acceptable as data integrity on those kinds of tables must be
maintained.
Database maintenance plan is in-placed to reorganized data and index pages,
scheduled to run once a w, during non-operation hours.
HDD defragmentation is scheduled to run twice a w, also during
non-operation hours.
The codes for the frequently used sales modules have been optimized to
ensure that transaction control is well handled, and unnecessary queries
removed.
HOWEVER WHEN THE UNLUCKY DAY OCCURRED…
Timeout occurs when user posts a sales transaction during the peak hours.
But the volume of transaction is similar to other peak hours during other
fine days!
I tried restarting the server and the client machines and applications but
the posting still timeout.
I even tried having only one user posting a transaction but that also timeou
t!
I checked the Profiler and it reveals that SQL Server is “stuck” while
attempting to insert some rows into a few tables at the start of the
transaction. These tables have small number of rows, from 10K to 200K each.
I
repeated the same test for only one user, and SQL Server remains “stuck”
as
well. BUT during fine days, SQL Server never has problem with those tables.
It can even insert data quickly into big tables with 2M+ rows!
I also checked the SQL EM Current Activities, and can find no tables being
blocked when only one user is posting. Tables are only blocked when more tha
n
one user is posting, and that is understandable coz SQL Server is “stuck
on
the 1st user’s transaction, thus blocking everyone else.
The SQL Server just become spastic, obsessed with the 1st (or only) user
transaction, never wanting to finish it off that I know it can.
And the weird thing is after 2-3 hours, everything goes back to normal, with
SQL Server at its best again.
PUZZLED…
The server specs is top-end; The program should be well optimized as far as
the frequently used sales modules are concerned; Maintenance Plans and
defragmentation scheduled tasks are in place; Heavy jobs such as Veritas
backup are only done during non-operation hours; It works fine for about
six-w, then it gets “stuck” on a few small tables, only to “unstuck
” after
2-3 hours break; The weirdest of all, it even timeouts when only one user
(having all the server and database resources to him /herself) is posting a
sales transaction!
Can anyone please kindly advice what are the possible causes and resolutions
for this anomalies be? Can the hardware spec affect it, even though it is
supposed to be high-end? Could other applications such as Veritas co-exist
with the SQL Server? Is SQL Server running any system jobs, e.g. Ghost
Cleanup, that can slow down its performance?
TQ in advance.Hi
The fact that it is stuck sounds like blocking issues.
If the application does not finish it's transaction on a specific set of
row(s) in a table, and another one comes in to work on the same row(s), the
2nd one has to wait.
When this happens, run sp_who2 and see what is blocking what.
Look up "blocks, avoiding" in books online.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"HardKhor" <HardKhor@.discussions.microsoft.com> wrote in message
news:B1960834-C93C-458E-BC88-792045D88F2C@.microsoft.com...
> Hi all,
> My production system is experiencing abnormal timeouts during posting of
> transaction. The abnormal part is:
> System usually works fine for about 6 ws; but one unlucky day, suddenly
> for no apparent reason, system experiences massive timeout for about 2 - 3
> hours; after that everything is fine again.
>
> A background on the production system:
> . It is a sales and stock control system. With a fair number (nothing
> massive) of sales transactions every operation days
> . Approx 50 client users
> . Developed using VB .Net, VS 2003
> . Running on .Net Framework 2.0
> . Running on SQL Server database
> . Supports multi-user, single database
> It is also running on a pretty high-end server (from what I was told) with
> spec:
> . HP ML 530 G2 machine
> . 2-processors, each 3 GHz, running Xeon HT
> . 4 GB ECC RAM
> . HDD running RAID 0 and RAID 1; Total disk space 200 GB, with 72 GB free
> . SQL Server 2003 standard edition with sp3
> . Windows 2003 Server standard edition
> . Running other s/w, mainly Norton Anti-Virus 9.0 corp. version and
> Veritas
> 9.1
>
> USUALLY DURING THE FINE DAYS.
> System works fine during both peak and off-peak hours with very rare
> timeouts. Those timeouts are caused mainly by updating of "constant"
> tables,
> such as stock when two customers are buying the same item at the same
> time.
> That is acceptable as data integrity on those kinds of tables must be
> maintained.
> Database maintenance plan is in-placed to reorganized data and index
> pages,
> scheduled to run once a w, during non-operation hours.
> HDD defragmentation is scheduled to run twice a w, also during
> non-operation hours.
> The codes for the frequently used sales modules have been optimized to
> ensure that transaction control is well handled, and unnecessary queries
> removed.
>
> HOWEVER WHEN THE UNLUCKY DAY OCCURRED.
> Timeout occurs when user posts a sales transaction during the peak hours.
> But the volume of transaction is similar to other peak hours during other
> fine days!
> I tried restarting the server and the client machines and applications but
> the posting still timeout.
> I even tried having only one user posting a transaction but that also
> timeout!
> I checked the Profiler and it reveals that SQL Server is "stuck" while
> attempting to insert some rows into a few tables at the start of the
> transaction. These tables have small number of rows, from 10K to 200K
> each. I
> repeated the same test for only one user, and SQL Server remains "stuck"
> as
> well. BUT during fine days, SQL Server never has problem with those
> tables.
> It can even insert data quickly into big tables with 2M+ rows!
> I also checked the SQL EM Current Activities, and can find no tables being
> blocked when only one user is posting. Tables are only blocked when more
> than
> one user is posting, and that is understandable coz SQL Server is "stuck"
> on
> the 1st user's transaction, thus blocking everyone else.
> The SQL Server just become spastic, obsessed with the 1st (or only) user
> transaction, never wanting to finish it off that I know it can.
> And the weird thing is after 2-3 hours, everything goes back to normal,
> with
> SQL Server at its best again.
>
> PUZZLED.
> The server specs is top-end; The program should be well optimized as far
> as
> the frequently used sales modules are concerned; Maintenance Plans and
> defragmentation scheduled tasks are in place; Heavy jobs such as Veritas
> backup are only done during non-operation hours; It works fine for about
> six-w, then it gets "stuck" on a few small tables, only to "unstuck"
> after
> 2-3 hours break; The weirdest of all, it even timeouts when only one user
> (having all the server and database resources to him /herself) is posting
> a
> sales transaction!
> Can anyone please kindly advice what are the possible causes and
> resolutions
> for this anomalies be? Can the hardware spec affect it, even though it is
> supposed to be high-end? Could other applications such as Veritas co-exist
> with the SQL Server? Is SQL Server running any system jobs, e.g. Ghost
> Cleanup, that can slow down its performance?
> TQ in advance.|||Hi,
TQ for reply.
I don't think it is a blocking issue coz EM Current Activities shows no
blocks, no locks and whatsoever, and the codes have been optimized to handle
transaction properly. And as mentioned, weird things like why everything
works fine for about six ws, but fails for 3 hours; and even
one-and-only-one user gets timeout during posting. The system just degraded
for no apparent reason.
TQ for the sp_who2 thou. Will try it out (fingers crossed) in abt six ws
time! ;)
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> The fact that it is stuck sounds like blocking issues.
> If the application does not finish it's transaction on a specific set of
> row(s) in a table, and another one comes in to work on the same row(s), th
e
> 2nd one has to wait.
> When this happens, run sp_who2 and see what is blocking what.
> Look up "blocks, avoiding" in books online.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "HardKhor" <HardKhor@.discussions.microsoft.com> wrote in message
> news:B1960834-C93C-458E-BC88-792045D88F2C@.microsoft.com...
>
>

A question about bulk insert and partitioned views

To all,
I posted this question in the server list and that may not have been the
appropriate place so I am posting here.
I have built a partitioned view exactly as described in BOL. I can insert
data into just fine and it places the values in the correct sub-tables
according to the check constraint.
I would like to do bulk inserts on this partitioned view but I get an error
message stating that this view cannot be a target of a bulk operation. I
did include the CHECK_CONTRAINTS setting to the bulk insert call.
My question is are bulk inserts allowed into partitioned views (I cannot
find anything in BOL that states they cannot) or am I missing something in
setting up the view?
Thanks.
--seanCreate an "instead of" trigger on your view and use option FIRE_TRIGGERS wit
h
BULK INSERT.
Example:
use northwind
go
exec master..xp_cmdshell 'bcp "select orderid, convert(char(8), orderdate,
112) from northwind.dbo.orders where orderdate >= ''19970101'' and orderdate
< ''19990101''" queryout "c:\temp\test.bcp" -S server_name -T -c'
go
create table dbo.t1 (
colA int not null primary key check (colA between 10400 and 10807),
colB datetime not null
)
go
create table dbo.t2 (
colA int not null primary key check (colA between 10808 and 11077),
colB datetime not null
)
go
create view dbo.vw_myview
as
select colA, colB from dbo.t1
union all
select colA, colB from dbo.t2
go
create trigger tr_vw_myview_io_ins on dbo.vw_myview
instead of insert
as
insert into dbo.t1
select * from inserted where colA between 10400 and 10807
insert into dbo.t2
select * from inserted where colA between 10808 and 11077
go
bulk insert northwind.dbo.[vw_myview]
from 'c:\temp\test.bcp'
with
(
fieldterminator = '\t',
rowterminator = '\n',
fire_triggers
)
go
select * from dbo.vw_myview where colA = 10810
go
drop view dbo.vw_myview
go
drop table dbo.t1, dbo.t2
go
AMB
"Sean Shanny" wrote:

> To all,
> I posted this question in the server list and that may not have been the
> appropriate place so I am posting here.
> I have built a partitioned view exactly as described in BOL. I can insert
> data into just fine and it places the values in the correct sub-tables
> according to the check constraint.
> I would like to do bulk inserts on this partitioned view but I get an erro
r
> message stating that this view cannot be a target of a bulk operation. I
> did include the CHECK_CONTRAINTS setting to the bulk insert call.
> My question is are bulk inserts allowed into partitioned views (I cannot
> find anything in BOL that states they cannot) or am I missing something in
> setting up the view?
> Thanks.
> --sean
>
>

A previous restore operation was interrupted and did not complete processing on file

Hi

I am new to Forum. So not sure if i am posting my problem uner the right topic.

We have a sql server 2005 enterprise edition 4 way cluster on windows 2003 advance server.

I am logshipping these database to a different server at a different location.

My logshipping went fine until one the cluster server failed and the server instance failed over to another node.

The backup that happened around that time got copied over to the secondary by the copy job.

The log file that got copied to the secondary server tried restoring and i think it failed int he middle of restoring it.

(You would think that the sql would knoe if the backup is in complete and will move on to the next file. Not sure what happened there.)

There is no indication of the *.TUF file in the directory where i have the log files.

I tried restoring it manually and i got the following error

Msg 4319, Level 16, State 3, Line 1

A previous restore operation was interrupted and did not complete processing on file 'sessionlog1'. Either restore the backup set that was interrupted or restart the restore sequence.

Msg 3013, Level 16, State 1, Line 1

RESTORE LOG is terminating abnormally.

I looked in the msdb..log_shipping_secondary_databases and looked for the last file that it restored and tried restoring it again with the following restore command by removing and adding some of the keywords that you see after the "WITH" clause.

MSFT do not recommand to use continne_after_error unless its absolutley necessary. I stilll get the above error.

restore log sessiondata

from disk = 'I:\sql13qasm\logs\sessiondata\sessiondata_20070901124516.trn'

with restart, CONTINUE_AFTER_ERROR, norecovery

When i add the restart int he with clause,

The restart-checkpoint file 'J:\Microsoft SQL Server\MSSQL.5\MSSQL\Backup\sessiondata.CKP' was not found. The RESTORE command will continue from the beginning as if RESTART had not been specified.

Msg 4319, Level 16, State 1, Line 1

A previous restore operation was interrupted and did not complete processing on file 'sessionlog1'. Either restore the backup set that was interrupted or restart the restore sequence.

Msg 3013, Level 16, State 1, Line 1

RESTORE LOG is terminating abnormally.

I checked it the backup directory and i can't locate the .CKP file.

Does anyone ever come accross this issue?

Is there anyother way i could recover this DB in a standby or norecovery mode.

Any kind of help to resolve this issue (beside copy the full backup and redo the whole log-shipping process again) would be appreciated. sicne my primary and secondary server are totally ina different location, i need to ship a tape, if i need a full backup. This is the 3rd time its happening on that cluster. its frustrating to ship a tape everytime this happens.

I think the log backup chain has been broken. Try doing a differential and log backup and restoring those on the secondary. If that doesn't work I think you'll need to go the full backup route again.

I'm not an expert on log shipping though - maybe someone else can chime in here?

|||

I can't take a differential now, since full back job happened already, after the failure.

:-S