Hi all,
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at n
o
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
15:30:34.683 DTCXact 16335154 sa
Any Ideas ?
Regards Tommy S.Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server
?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy S?derkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) a
re
> over six seconds, but the individual SQL statements (sp's) are executed at
no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> 15:30:34.683 DTCXact 16335154 sa
> Any Ideas ?
> Regards Tommy S.
>|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
[vbcol=seagreen]
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the serv
er?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy S?derkvist" wrote:
>|||"Tommy S?derkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
[vbcol=seagreen]
> /Tommy
> "Olu Adedeji" wrote:
>
server?[vbcol=seagreen]
(Commit) are[vbcol=seagreen]
executed at no[vbcol=seagreen]
Showing posts with label sql2000. Show all posts
Showing posts with label sql2000. Show all posts
Friday, March 30, 2012
Long running SQLTransaction
Hi all,
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
15:30:34.683 DTCXact 16335154 sa
Any Ideas ?
Regards Tommy S.Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy Söderkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> 15:30:34.683 DTCXact 16335154 sa
> Any Ideas ?
> Regards Tommy S.
>|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy Söderkvist" wrote:
> > Hi all,
> > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > When running SQL Profiler the duration for some SQLTransactions (Commit) are
> > over six seconds, but the individual SQL statements (sp's) are executed at no
> > time at all.
> > I've used sp_lock but there are no locks.
> > Here's an extract from SQLProfiler:
> > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > 15:30:34.683 DTCXact 16335154 sa
> > Any Ideas ?
> > Regards Tommy S.
> >|||"Tommy Söderkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
> /Tommy
> "Olu Adedeji" wrote:
> > Check out master..sysprocesses and find out what the waittypes are
> > to determine what is causing the extended commit operation.
> >
> > is the Tlog file on the same disk as the data file . .how busy is the
server?
> > is this constantly reproduceable? or is it intermittent?
> >
> > HTH
> >
> > "Tommy Söderkvist" wrote:
> >
> > > Hi all,
> > > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > > When running SQL Profiler the duration for some SQLTransactions
(Commit) are
> > > over six seconds, but the individual SQL statements (sp's) are
executed at no
> > > time at all.
> > > I've used sp_lock but there are no locks.
> > > Here's an extract from SQLProfiler:
> > > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > > 15:30:34.683 DTCXact 16335154 sa
> > > Any Ideas ?
> > > Regards Tommy S.
> > >
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
15:30:34.683 DTCXact 16335154 sa
Any Ideas ?
Regards Tommy S.Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy Söderkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> 15:30:34.683 DTCXact 16335154 sa
> Any Ideas ?
> Regards Tommy S.
>|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy Söderkvist" wrote:
> > Hi all,
> > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > When running SQL Profiler the duration for some SQLTransactions (Commit) are
> > over six seconds, but the individual SQL statements (sp's) are executed at no
> > time at all.
> > I've used sp_lock but there are no locks.
> > Here's an extract from SQLProfiler:
> > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > 15:30:34.683 DTCXact 16335154 sa
> > Any Ideas ?
> > Regards Tommy S.
> >|||"Tommy Söderkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
> /Tommy
> "Olu Adedeji" wrote:
> > Check out master..sysprocesses and find out what the waittypes are
> > to determine what is causing the extended commit operation.
> >
> > is the Tlog file on the same disk as the data file . .how busy is the
server?
> > is this constantly reproduceable? or is it intermittent?
> >
> > HTH
> >
> > "Tommy Söderkvist" wrote:
> >
> > > Hi all,
> > > we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> > > When running SQL Profiler the duration for some SQLTransactions
(Commit) are
> > > over six seconds, but the individual SQL statements (sp's) are
executed at no
> > > time at all.
> > > I've used sp_lock but there are no locks.
> > > Here's an extract from SQLProfiler:
> > > SQLTransaction Commit 6796 5 2005-03-04 15:30:27.887 2005-03-04
> > > 15:30:34.683 DTCXact 16335154 sa
> > > Any Ideas ?
> > > Regards Tommy S.
> > >
Long running SQLTransaction
Hi all,
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
15:30:34.683DTCXact16335154sa
Any Ideas ?
Regards Tommy S.
Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy S?derkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
> 15:30:34.683DTCXact16335154sa
> Any Ideas ?
> Regards Tommy S.
>
|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
[vbcol=seagreen]
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy S?derkvist" wrote:
|||"Tommy S?derkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
[vbcol=seagreen]
> /Tommy
> "Olu Adedeji" wrote:
server?[vbcol=seagreen]
(Commit) are[vbcol=seagreen]
executed at no[vbcol=seagreen]
we have a strange problem in SQL2000 SP3a with SQLTransaction's.
When running SQL Profiler the duration for some SQLTransactions (Commit) are
over six seconds, but the individual SQL statements (sp's) are executed at no
time at all.
I've used sp_lock but there are no locks.
Here's an extract from SQLProfiler:
SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
15:30:34.683DTCXact16335154sa
Any Ideas ?
Regards Tommy S.
Check out master..sysprocesses and find out what the waittypes are
to determine what is causing the extended commit operation.
is the Tlog file on the same disk as the data file . .how busy is the server?
is this constantly reproduceable? or is it intermittent?
HTH
"Tommy S?derkvist" wrote:
> Hi all,
> we have a strange problem in SQL2000 SP3a with SQLTransaction's.
> When running SQL Profiler the duration for some SQLTransactions (Commit) are
> over six seconds, but the individual SQL statements (sp's) are executed at no
> time at all.
> I've used sp_lock but there are no locks.
> Here's an extract from SQLProfiler:
> SQLTransactionCommit679652005-03-04 15:30:27.8872005-03-04
> 15:30:34.683DTCXact16335154sa
> Any Ideas ?
> Regards Tommy S.
>
|||Thanks,
I will try to check out the waittypes the next time I see a long running
transaction.
Yes, the log and the datafile are located on the same disk.
The CPU's (4 of them) are almost idle.
The problem is intermittent and it doesn't seem to be dependent on the
number of users, it can occur at early evening when the number of users
decrease significant.
/Tommy
"Olu Adedeji" wrote:
[vbcol=seagreen]
> Check out master..sysprocesses and find out what the waittypes are
> to determine what is causing the extended commit operation.
> is the Tlog file on the same disk as the data file . .how busy is the server?
> is this constantly reproduceable? or is it intermittent?
> HTH
> "Tommy S?derkvist" wrote:
|||"Tommy S?derkvist" <TommySderkvist@.discussions.microsoft.com> schrieb im
Newsbeitrag news:72BF587D-E3CF-41FE-9EC8-5681C62E472B@.microsoft.com...
> Thanks,
> I will try to check out the waittypes the next time I see a long running
> transaction.
> Yes, the log and the datafile are located on the same disk.
> The CPU's (4 of them) are almost idle.
> The problem is intermittent and it doesn't seem to be dependent on the
> number of users, it can occur at early evening when the number of users
> decrease significant.
My guess would be that you have an IO bottleneck which makes tx log
writing slow. You could use perfmon to verify this theory.
robert
[vbcol=seagreen]
> /Tommy
> "Olu Adedeji" wrote:
server?[vbcol=seagreen]
(Commit) are[vbcol=seagreen]
executed at no[vbcol=seagreen]
long running RESTORE
Hi all !
I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
2000(SP3). It takes a few minutes to restore it on another box which has
enough resurses, but when I tried to do the same on a box that is a bit old
and not so powerfull I just couldn't wait until it's done, - i canceled
restore operation. As a workaround I detached DB file and then attached them
on that box. But I'm still wondering is there another way to restore DB, may
be group by group or ...?
Thanks a lot in advance,
Alex
Backup and restore
and
sp_detach_db and sp_attach_db
are the best options
You could also try using DTS, but that would probably involve much more
effort on your part.
Keith
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>
|||Did you restore the database on the 'old box' when the database was not yet
created? If this was the first time, the 5 Gig file needs to be created
first before the restore can start, and depending on the speed of your disk
controllers, this might take some time. When you subsequently restore the
database again, don't delete the old database first.
Since you already have the database on the old box, try restoring using the
normal way, and see if it still takes as long. And by any chance, are you
using compressed folders?
Peter Yeoh
http://www.yohz.com
Need smaller SQL2K backups? Try MiniSQLBackup
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>
|||Yes, I created DB before restoring with two file groups 2 G each and log
file. And I wasn't using compressed folder. My guess is maybe I wasn't
patient enough although I waited for about half an hour to let it finish.
But that 'old box' is really slow and that could be the case. I'll give it
another try and be more patien this time.
Thank you,
Alex
"Peter Yeoh" <nospam@.nospam.com> wrote in message
news:u2AMSofbEHA.1732@.TK2MSFTNGP09.phx.gbl...
> Did you restore the database on the 'old box' when the database was not
yet
> created? If this was the first time, the 5 Gig file needs to be created
> first before the restore can start, and depending on the speed of your
disk
> controllers, this might take some time. When you subsequently restore the
> database again, don't delete the old database first.
> Since you already have the database on the old box, try restoring using
the[vbcol=seagreen]
> normal way, and see if it still takes as long. And by any chance, are you
> using compressed folders?
> Peter Yeoh
> http://www.yohz.com
> Need smaller SQL2K backups? Try MiniSQLBackup
>
> "Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
> news:10fo5ivqif63e54@.corp.supernews.com...
has
> old
> them
> may
>
I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
2000(SP3). It takes a few minutes to restore it on another box which has
enough resurses, but when I tried to do the same on a box that is a bit old
and not so powerfull I just couldn't wait until it's done, - i canceled
restore operation. As a workaround I detached DB file and then attached them
on that box. But I'm still wondering is there another way to restore DB, may
be group by group or ...?
Thanks a lot in advance,
Alex
Backup and restore
and
sp_detach_db and sp_attach_db
are the best options
You could also try using DTS, but that would probably involve much more
effort on your part.
Keith
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>
|||Did you restore the database on the 'old box' when the database was not yet
created? If this was the first time, the 5 Gig file needs to be created
first before the restore can start, and depending on the speed of your disk
controllers, this might take some time. When you subsequently restore the
database again, don't delete the old database first.
Since you already have the database on the old box, try restoring using the
normal way, and see if it still takes as long. And by any chance, are you
using compressed folders?
Peter Yeoh
http://www.yohz.com
Need smaller SQL2K backups? Try MiniSQLBackup
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>
|||Yes, I created DB before restoring with two file groups 2 G each and log
file. And I wasn't using compressed folder. My guess is maybe I wasn't
patient enough although I waited for about half an hour to let it finish.
But that 'old box' is really slow and that could be the case. I'll give it
another try and be more patien this time.
Thank you,
Alex
"Peter Yeoh" <nospam@.nospam.com> wrote in message
news:u2AMSofbEHA.1732@.TK2MSFTNGP09.phx.gbl...
> Did you restore the database on the 'old box' when the database was not
yet
> created? If this was the first time, the 5 Gig file needs to be created
> first before the restore can start, and depending on the speed of your
disk
> controllers, this might take some time. When you subsequently restore the
> database again, don't delete the old database first.
> Since you already have the database on the old box, try restoring using
the[vbcol=seagreen]
> normal way, and see if it still takes as long. And by any chance, are you
> using compressed folders?
> Peter Yeoh
> http://www.yohz.com
> Need smaller SQL2K backups? Try MiniSQLBackup
>
> "Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
> news:10fo5ivqif63e54@.corp.supernews.com...
has
> old
> them
> may
>
long running RESTORE
Hi all !
I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
2000(SP3). It takes a few minutes to restore it on another box which has
enough resurses, but when I tried to do the same on a box that is a bit old
and not so powerfull I just couldn't wait until it's done, - i canceled
restore operation. As a workaround I detached DB file and then attached them
on that box. But I'm still wondering is there another way to restore DB, may
be group by group or ...?
--
Thanks a lot in advance,
AlexBackup and restore
and
sp_detach_db and sp_attach_db
are the best options
You could also try using DTS, but that would probably involve much more
effort on your part.
Keith
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>|||Did you restore the database on the 'old box' when the database was not yet
created? If this was the first time, the 5 Gig file needs to be created
first before the restore can start, and depending on the speed of your disk
controllers, this might take some time. When you subsequently restore the
database again, don't delete the old database first.
Since you already have the database on the old box, try restoring using the
normal way, and see if it still takes as long. And by any chance, are you
using compressed folders?
Peter Yeoh
http://www.yohz.com
Need smaller SQL2K backups? Try MiniSQLBackup
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>|||Yes, I created DB before restoring with two file groups 2 G each and log
file. And I wasn't using compressed folder. My guess is maybe I wasn't
patient enough although I waited for about half an hour to let it finish.
But that 'old box' is really slow and that could be the case. I'll give it
another try and be more patien this time.
Thank you,
Alex
"Peter Yeoh" <nospam@.nospam.com> wrote in message
news:u2AMSofbEHA.1732@.TK2MSFTNGP09.phx.gbl...
> Did you restore the database on the 'old box' when the database was not
yet
> created? If this was the first time, the 5 Gig file needs to be created
> first before the restore can start, and depending on the speed of your
disk
> controllers, this might take some time. When you subsequently restore the
> database again, don't delete the old database first.
> Since you already have the database on the old box, try restoring using
the
> normal way, and see if it still takes as long. And by any chance, are you
> using compressed folders?
> Peter Yeoh
> http://www.yohz.com
> Need smaller SQL2K backups? Try MiniSQLBackup
>
> "Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
> news:10fo5ivqif63e54@.corp.supernews.com...
has[vbcol=seagreen]
> old
> them
> may
>
I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
2000(SP3). It takes a few minutes to restore it on another box which has
enough resurses, but when I tried to do the same on a box that is a bit old
and not so powerfull I just couldn't wait until it's done, - i canceled
restore operation. As a workaround I detached DB file and then attached them
on that box. But I'm still wondering is there another way to restore DB, may
be group by group or ...?
--
Thanks a lot in advance,
AlexBackup and restore
and
sp_detach_db and sp_attach_db
are the best options
You could also try using DTS, but that would probably involve much more
effort on your part.
Keith
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>|||Did you restore the database on the 'old box' when the database was not yet
created? If this was the first time, the 5 Gig file needs to be created
first before the restore can start, and depending on the speed of your disk
controllers, this might take some time. When you subsequently restore the
database again, don't delete the old database first.
Since you already have the database on the old box, try restoring using the
normal way, and see if it still takes as long. And by any chance, are you
using compressed folders?
Peter Yeoh
http://www.yohz.com
Need smaller SQL2K backups? Try MiniSQLBackup
"Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
news:10fo5ivqif63e54@.corp.supernews.com...
> Hi all !
> I have 5 GB backup file of DB running in SIMPLE recovery mode on SQL
> 2000(SP3). It takes a few minutes to restore it on another box which has
> enough resurses, but when I tried to do the same on a box that is a bit
old
> and not so powerfull I just couldn't wait until it's done, - i canceled
> restore operation. As a workaround I detached DB file and then attached
them
> on that box. But I'm still wondering is there another way to restore DB,
may
> be group by group or ...?
> --
> Thanks a lot in advance,
> Alex
>|||Yes, I created DB before restoring with two file groups 2 G each and log
file. And I wasn't using compressed folder. My guess is maybe I wasn't
patient enough although I waited for about half an hour to let it finish.
But that 'old box' is really slow and that could be the case. I'll give it
another try and be more patien this time.
Thank you,
Alex
"Peter Yeoh" <nospam@.nospam.com> wrote in message
news:u2AMSofbEHA.1732@.TK2MSFTNGP09.phx.gbl...
> Did you restore the database on the 'old box' when the database was not
yet
> created? If this was the first time, the 5 Gig file needs to be created
> first before the restore can start, and depending on the speed of your
disk
> controllers, this might take some time. When you subsequently restore the
> database again, don't delete the old database first.
> Since you already have the database on the old box, try restoring using
the
> normal way, and see if it still takes as long. And by any chance, are you
> using compressed folders?
> Peter Yeoh
> http://www.yohz.com
> Need smaller SQL2K backups? Try MiniSQLBackup
>
> "Alex" <amakarov_removethis_@.healthmetrx.com> wrote in message
> news:10fo5ivqif63e54@.corp.supernews.com...
has[vbcol=seagreen]
> old
> them
> may
>
Wednesday, March 21, 2012
Logs NOT truncating with Arcserve v9?
Anyone using Brightstor Arcserve v9 + the SQL agent to backup their SQL
databases?
We are using it to backup all our SQL2000 databases (15) and it works just
fine *except* even though it is configured to do a 'complete backup' of each
database it doesnt truncate the transaction log at the end...with the
consequence that the logs bloat out the many Gigabytes.
I understood that the default behaviour for a 'complete backup' was to
backup the database+logs then truncate?
The arcserve agent give the option to run a 'transaction log' backup...(ie
logs only) but that is not what we want.
Any ideas on how to get it to truncate those logs once the backup is
completed sucessfully (other than use another product ;)
NB the CA support site for Arcserve is *REALLY* crap - every query returns
hundreds of product releases and adverts for their bloody software but no
technical information. Every time they change it, it gets worse
Al Blake, Canberra, AustraliaAl,
> I understood that the default behaviour for a 'complete backup' was to
> backup the database+logs then truncate?
You would have to ask Arcserve about this. In SQL Server, BACKUP DATABASE
does not empty the log. You either do regular log backups or put the
database in simple recovery mode. A tip is to run Profiler while the
Arcserve job is executed to catch what is *really* going on.
Also, information about shrinking files etc (as I guess you might want to do
this) is found at below side, see the links in the text:
http://www.karaszi.com/sqlserver/info_dont_shrink.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Al Blake" <al@.blakes.net> wrote in message
news:eBeoGjGEEHA.3804@.TK2MSFTNGP09.phx.gbl...
> Anyone using Brightstor Arcserve v9 + the SQL agent to backup their SQL
> databases?
> We are using it to backup all our SQL2000 databases (15) and it works just
> fine *except* even though it is configured to do a 'complete backup' of
each
> database it doesnt truncate the transaction log at the end...with the
> consequence that the logs bloat out the many Gigabytes.
> I understood that the default behaviour for a 'complete backup' was to
> backup the database+logs then truncate?
> The arcserve agent give the option to run a 'transaction log' backup...(ie
> logs only) but that is not what we want.
> Any ideas on how to get it to truncate those logs once the backup is
> completed sucessfully (other than use another product ;)
> NB the CA support site for Arcserve is *REALLY* crap - every query returns
> hundreds of product releases and adverts for their bloody software but no
> technical information. Every time they change it, it gets worse
> Al Blake, Canberra, Australia
>
databases?
We are using it to backup all our SQL2000 databases (15) and it works just
fine *except* even though it is configured to do a 'complete backup' of each
database it doesnt truncate the transaction log at the end...with the
consequence that the logs bloat out the many Gigabytes.
I understood that the default behaviour for a 'complete backup' was to
backup the database+logs then truncate?
The arcserve agent give the option to run a 'transaction log' backup...(ie
logs only) but that is not what we want.
Any ideas on how to get it to truncate those logs once the backup is
completed sucessfully (other than use another product ;)
NB the CA support site for Arcserve is *REALLY* crap - every query returns
hundreds of product releases and adverts for their bloody software but no
technical information. Every time they change it, it gets worse
Al Blake, Canberra, AustraliaAl,
> I understood that the default behaviour for a 'complete backup' was to
> backup the database+logs then truncate?
You would have to ask Arcserve about this. In SQL Server, BACKUP DATABASE
does not empty the log. You either do regular log backups or put the
database in simple recovery mode. A tip is to run Profiler while the
Arcserve job is executed to catch what is *really* going on.
Also, information about shrinking files etc (as I guess you might want to do
this) is found at below side, see the links in the text:
http://www.karaszi.com/sqlserver/info_dont_shrink.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Al Blake" <al@.blakes.net> wrote in message
news:eBeoGjGEEHA.3804@.TK2MSFTNGP09.phx.gbl...
> Anyone using Brightstor Arcserve v9 + the SQL agent to backup their SQL
> databases?
> We are using it to backup all our SQL2000 databases (15) and it works just
> fine *except* even though it is configured to do a 'complete backup' of
each
> database it doesnt truncate the transaction log at the end...with the
> consequence that the logs bloat out the many Gigabytes.
> I understood that the default behaviour for a 'complete backup' was to
> backup the database+logs then truncate?
> The arcserve agent give the option to run a 'transaction log' backup...(ie
> logs only) but that is not what we want.
> Any ideas on how to get it to truncate those logs once the backup is
> completed sucessfully (other than use another product ;)
> NB the CA support site for Arcserve is *REALLY* crap - every query returns
> hundreds of product releases and adverts for their bloody software but no
> technical information. Every time they change it, it gets worse
> Al Blake, Canberra, Australia
>
Monday, March 12, 2012
Logins from SQL7 to SQL2000
We are upgraded our vendor software (Jenzabar EX) from SQL7 to SQL2000. In the process, we are also moving the databases to a new server. Everything seemed to go fine until we tried to log on to one of Jenzabar EX modules. We have tried several differe
nt things, including the sp_change_users (which failed because of the @.action clause). We've tried running that huge script included in the Knowledge Base article. We also have tried using the transfer login wizard. Which, report success, but the login
s still do not work.
Could we have possibly missed a step somewhere? Is there something else we can try? I sure would greatly appreciate any advice or assistance.
Thanks!
Karma
What is the exact problem you are having when you login from this
application?
Rand
This posting is provided "as is" with no warranties and confers no rights.
nt things, including the sp_change_users (which failed because of the @.action clause). We've tried running that huge script included in the Knowledge Base article. We also have tried using the transfer login wizard. Which, report success, but the login
s still do not work.
Could we have possibly missed a step somewhere? Is there something else we can try? I sure would greatly appreciate any advice or assistance.
Thanks!
Karma
What is the exact problem you are having when you login from this
application?
Rand
This posting is provided "as is" with no warranties and confers no rights.
Logins from SQL7 to SQL2000
We are upgraded our vendor software (Jenzabar EX) from SQL7 to SQL2000. In
the process, we are also moving the databases to a new server. Everything s
eemed to go fine until we tried to log on to one of Jenzabar EX modules. We
have tried several differe
nt things, including the sp_change_users (which failed because of the @.actio
n clause). We've tried running that huge script included in the Knowledge B
ase article. We also have tried using the transfer login wizard. Which, re
port success, but the login
s still do not work.
Could we have possibly missed a step somewhere? Is there something else we
can try? I sure would greatly appreciate any advice or assistance.
Thanks!
KarmaWhat is the exact problem you are having when you login from this
application?
Rand
This posting is provided "as is" with no warranties and confers no rights.
the process, we are also moving the databases to a new server. Everything s
eemed to go fine until we tried to log on to one of Jenzabar EX modules. We
have tried several differe
nt things, including the sp_change_users (which failed because of the @.actio
n clause). We've tried running that huge script included in the Knowledge B
ase article. We also have tried using the transfer login wizard. Which, re
port success, but the login
s still do not work.
Could we have possibly missed a step somewhere? Is there something else we
can try? I sure would greatly appreciate any advice or assistance.
Thanks!
KarmaWhat is the exact problem you are having when you login from this
application?
Rand
This posting is provided "as is" with no warranties and confers no rights.
Subscribe to:
Posts (Atom)