Has anyone sees issues where although the exec plans are the same , theres
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>
|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue's
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>
|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization[vbcol=seagreen]
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
theres[vbcol=seagreen]
at[vbcol=seagreen]
when[vbcol=seagreen]
long[vbcol=seagreen]
these[vbcol=seagreen]
then[vbcol=seagreen]
reboot[vbcol=seagreen]
Showing posts with label plans. Show all posts
Showing posts with label plans. Show all posts
Wednesday, March 21, 2012
n/w issues and had to reboot.
Has anyone sees issues where although the exec plans are the same , theres
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue'
s
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization[vbcol=seagreen]
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
>
theres[vbcol=seagreen]
at[vbcol=seagreen]
when[vbcol=seagreen]
long[vbcol=seagreen]
these[vbcol=seagreen]
then[vbcol=seagreen]
reboot[vbcol=seagreen]
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue'
s
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as lon
g
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain thes
e
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a rebo
ot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization[vbcol=seagreen]
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
>
theres[vbcol=seagreen]
at[vbcol=seagreen]
when[vbcol=seagreen]
long[vbcol=seagreen]
these[vbcol=seagreen]
then[vbcol=seagreen]
reboot[vbcol=seagreen]
n/w issues and had to reboot.
Has anyone sees issues where although the exec plans are the same , theres
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue's
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
> > Has anyone sees issues where although the exec plans are the same ,
theres
> > no blocking, and identical hardware that the query would perform slower
at
> > times to return the results to the client whereas it runs much faster
when
> > run on the same box. The query return a few million rows.. It takes as
long
> > as 1 hr when its slow and as fast as 5 mins when its normal to obtain
these
> > results on the client.
> >
> > Even stopping and starting SQL doesnt work. I just have to reboot and
then
> > its all fast again. I am thinking its being choked someplace.
> > I have seen this same behaviour on another server as well. and only a
reboot
> > would work. No messages in the log, nothing..
> >
> > A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
> >
> >
> >
> >sql
no blocking, and identical hardware that the query would perform slower at
times to return the results to the client whereas it runs much faster when
run on the same box. The query return a few million rows.. It takes as long
as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
results on the client.
Even stopping and starting SQL doesnt work. I just have to reboot and then
its all fast again. I am thinking its being choked someplace.
I have seen this same behaviour on another server as well. and only a reboot
would work. No messages in the log, nothing..
A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003Try sp_updatestats
I had simillar problem, VB6 client ran very slow sometimes, but the same
query (meanwhile!) ran fast in QA.
tv
Hassan napsal(a):
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Have your done profiling and perf-mon'ing of the boxes during these phases?
What are your cache hit ratio's like? Are you suffereing from disk IO queue's
going excessive? Are you having excessive paging? What does CPU utilization
look like?
When it takes 5 minutes, is it after a few iterations (i.e. data has been
cached by previous runs), etc.
"Hassan" wrote:
> Has anyone sees issues where although the exec plans are the same , theres
> no blocking, and identical hardware that the query would perform slower at
> times to return the results to the client whereas it runs much faster when
> run on the same box. The query return a few million rows.. It takes as long
> as 1 hr when its slow and as fast as 5 mins when its normal to obtain these
> results on the client.
> Even stopping and starting SQL doesnt work. I just have to reboot and then
> its all fast again. I am thinking its being choked someplace.
> I have seen this same behaviour on another server as well. and only a reboot
> would work. No messages in the log, nothing..
> A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
>
>|||Even a restart of SQL Service wont help.. But a reboot of a server sure
does fix it
"Wanderer" <Wanderer@.discussions.microsoft.com> wrote in message
news:957C21BB-A9EE-4E33-8903-205053E55821@.microsoft.com...
> Have your done profiling and perf-mon'ing of the boxes during these
phases?
> What are your cache hit ratio's like? Are you suffereing from disk IO
queue's
> going excessive? Are you having excessive paging? What does CPU
utilization
> look like?
> When it takes 5 minutes, is it after a few iterations (i.e. data has been
> cached by previous runs), etc.
> "Hassan" wrote:
> > Has anyone sees issues where although the exec plans are the same ,
theres
> > no blocking, and identical hardware that the query would perform slower
at
> > times to return the results to the client whereas it runs much faster
when
> > run on the same box. The query return a few million rows.. It takes as
long
> > as 1 hr when its slow and as fast as 5 mins when its normal to obtain
these
> > results on the client.
> >
> > Even stopping and starting SQL doesnt work. I just have to reboot and
then
> > its all fast again. I am thinking its being choked someplace.
> > I have seen this same behaviour on another server as well. and only a
reboot
> > would work. No messages in the log, nothing..
> >
> > A reboot always solves it. Any idea why.. Using SQL 2000 on Windows 2003
> >
> >
> >
> >sql
Monday, March 12, 2012
Mysterious backup jobs
For some reasons, my SQL server 2K keeps running some backup jobs whose
sources I cannot locate. I looked into the Database Maintenance Plans and
found only 1 plan I created myself. The job list in SQLserver logs contain
both my plan and activities from this mysterious plan.
Please help me to locate and get rid of these jobs. Below is the log for 1
of them:
Database backed up: Database: Invoices, creation date(time):
2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
11:390:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE:
{'DBASQL_DB_Invoices_PID1352TID4860BID0T
S1696503312VD0'}).
Thanks a million.
BillIt may be a job run by 3rd party backup s/w. Do you use any? And you can
run profiler on that DB to get more clue.....
"Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
I'll check my Arcserve backup application to see if it's the case.
Bill
"ME" <PLEASE!> wrote in message
news:O$c1hE52DHA.2000@.TK2MSFTNGP11.phx.gbl...
sources I cannot locate. I looked into the Database Maintenance Plans and
found only 1 plan I created myself. The job list in SQLserver logs contain
both my plan and activities from this mysterious plan.
Please help me to locate and get rid of these jobs. Below is the log for 1
of them:
Database backed up: Database: Invoices, creation date(time):
2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
11:390:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE:
{'DBASQL_DB_Invoices_PID1352TID4860BID0T
S1696503312VD0'}).
Thanks a million.
BillIt may be a job run by 3rd party backup s/w. Do you use any? And you can
run profiler on that DB to get more clue.....
"Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
quote:|||Thanks ME!
> For some reasons, my SQL server 2K keeps running some backup jobs whose
> sources I cannot locate. I looked into the Database Maintenance Plans and
> found only 1 plan I created myself. The job list in SQLserver logs contain
> both my plan and activities from this mysterious plan.
> Please help me to locate and get rid of these jobs. Below is the log for 1
> of them:
> Database backed up: Database: Invoices, creation date(time):
> 2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
> 11:390:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=VIRTUAL_DEVICE:
> {'DBASQL_DB_Invoices_PID1352TID4860BID0T
S1696503312VD0'}).
> Thanks a million.
> Bill
>
I'll check my Arcserve backup application to see if it's the case.
Bill
"ME" <PLEASE!> wrote in message
news:O$c1hE52DHA.2000@.TK2MSFTNGP11.phx.gbl...
quote:
> It may be a job run by 3rd party backup s/w. Do you use any? And you can
> run profiler on that DB to get more clue.....
>
> "Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
> news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
and[QUOTE]
contain[QUOTE]
1[QUOTE]
>
Mysterious backup jobs
For some reasons, my SQL server 2K keeps running some backup jobs whose
sources I cannot locate. I looked into the Database Maintenance Plans and
found only 1 plan I created myself. The job list in SQLserver logs contain
both my plan and activities from this mysterious plan.
Please help me to locate and get rid of these jobs. Below is the log for 1
of them:
Database backed up: Database: Invoices, creation date(time):
2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
11:390:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE:
{'DBASQL_DB_Invoices_PID1352TID4860BID0TS1696503312VD0'}).
Thanks a million.
BillIt may be a job run by 3rd party backup s/w. Do you use any? And you can
run profiler on that DB to get more clue.....
"Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
> For some reasons, my SQL server 2K keeps running some backup jobs whose
> sources I cannot locate. I looked into the Database Maintenance Plans and
> found only 1 plan I created myself. The job list in SQLserver logs contain
> both my plan and activities from this mysterious plan.
> Please help me to locate and get rid of these jobs. Below is the log for 1
> of them:
> Database backed up: Database: Invoices, creation date(time):
> 2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
> 11:390:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=VIRTUAL_DEVICE:
> {'DBASQL_DB_Invoices_PID1352TID4860BID0TS1696503312VD0'}).
> Thanks a million.
> Bill
>|||Thanks ME!
I'll check my Arcserve backup application to see if it's the case.
Bill
"ME" <PLEASE!> wrote in message
news:O$c1hE52DHA.2000@.TK2MSFTNGP11.phx.gbl...
> It may be a job run by 3rd party backup s/w. Do you use any? And you can
> run profiler on that DB to get more clue.....
>
> "Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
> news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
> > For some reasons, my SQL server 2K keeps running some backup jobs whose
> > sources I cannot locate. I looked into the Database Maintenance Plans
and
> > found only 1 plan I created myself. The job list in SQLserver logs
contain
> > both my plan and activities from this mysterious plan.
> > Please help me to locate and get rid of these jobs. Below is the log for
1
> > of them:
> >
> > Database backed up: Database: Invoices, creation date(time):
> > 2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
> > 11:390:1, number of dump devices: 1, device information: (FILE=1,
> > TYPE=VIRTUAL_DEVICE:
> > {'DBASQL_DB_Invoices_PID1352TID4860BID0TS1696503312VD0'}).
> >
> > Thanks a million.
> > Bill
> >
> >
>
sources I cannot locate. I looked into the Database Maintenance Plans and
found only 1 plan I created myself. The job list in SQLserver logs contain
both my plan and activities from this mysterious plan.
Please help me to locate and get rid of these jobs. Below is the log for 1
of them:
Database backed up: Database: Invoices, creation date(time):
2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
11:390:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE:
{'DBASQL_DB_Invoices_PID1352TID4860BID0TS1696503312VD0'}).
Thanks a million.
BillIt may be a job run by 3rd party backup s/w. Do you use any? And you can
run profiler on that DB to get more clue.....
"Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
> For some reasons, my SQL server 2K keeps running some backup jobs whose
> sources I cannot locate. I looked into the Database Maintenance Plans and
> found only 1 plan I created myself. The job list in SQLserver logs contain
> both my plan and activities from this mysterious plan.
> Please help me to locate and get rid of these jobs. Below is the log for 1
> of them:
> Database backed up: Database: Invoices, creation date(time):
> 2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
> 11:390:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=VIRTUAL_DEVICE:
> {'DBASQL_DB_Invoices_PID1352TID4860BID0TS1696503312VD0'}).
> Thanks a million.
> Bill
>|||Thanks ME!
I'll check my Arcserve backup application to see if it's the case.
Bill
"ME" <PLEASE!> wrote in message
news:O$c1hE52DHA.2000@.TK2MSFTNGP11.phx.gbl...
> It may be a job run by 3rd party backup s/w. Do you use any? And you can
> run profiler on that DB to get more clue.....
>
> "Bill Nguyen" <billn_nospam_please@.jaco.com> wrote in message
> news:OIXSx742DHA.3224@.tk2msftngp13.phx.gbl...
> > For some reasons, my SQL server 2K keeps running some backup jobs whose
> > sources I cannot locate. I looked into the Database Maintenance Plans
and
> > found only 1 plan I created myself. The job list in SQLserver logs
contain
> > both my plan and activities from this mysterious plan.
> > Please help me to locate and get rid of these jobs. Below is the log for
1
> > of them:
> >
> > Database backed up: Database: Invoices, creation date(time):
> > 2002/08/09(09:11:51), pages dumped: 232, first LSN: 11:388:1, last LSN:
> > 11:390:1, number of dump devices: 1, device information: (FILE=1,
> > TYPE=VIRTUAL_DEVICE:
> > {'DBASQL_DB_Invoices_PID1352TID4860BID0TS1696503312VD0'}).
> >
> > Thanks a million.
> > Bill
> >
> >
>
Subscribe to:
Posts (Atom)