Hi,
We have specific problem here. We have very large database (1TB) on one
server, and we need to set up log shipping to another server. Problem is that
we don't make regular sql server backups on the source server because of
obvious reason (it would take too long). Therefore we cannot restore database
in standby mode on the standby server. The only way to do database restore in
our case is to use BCV software (disk subsystem on both servers is EMC), and
that software doesn't have option od leaving database in standby mode. My
question is "is there any way to put database into standby mode, regardless
that is hasn't been restored using sql server native restore procedure?".
Servers are sql server 2000, service pack 3.
ThanksEven if you could put it into Standby mode, you wouldnt be able to apply
additional changes without TLog backups. I dont know if there is an option of
new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
"Pedja" wrote:
> Hi,
> We have specific problem here. We have very large database (1TB) on one
> server, and we need to set up log shipping to another server. Problem is that
> we don't make regular sql server backups on the source server because of
> obvious reason (it would take too long). Therefore we cannot restore database
> in standby mode on the standby server. The only way to do database restore in
> our case is to use BCV software (disk subsystem on both servers is EMC), and
> that software doesn't have option od leaving database in standby mode. My
> question is "is there any way to put database into standby mode, regardless
> that is hasn't been restored using sql server native restore procedure?".
> Servers are sql server 2000, service pack 3.
> Thanks|||Transaction log backups are OK for this scenario. I would be able to backup
transaction log i.e. every 2 hours, copy tl backup to the new sever, and
restore it there. It is full database backup that I cannot apply in this
scenario, because it would take too long. So if I could set secondary
database which is restored using BCV (not native backup), to standby mode,
I'd be able to apply log shipping scenario.
Even LiteSpeed wouldn't help. This database doesn't have much text fields,
so I don't think that compression would be that good. Even if I'd get 50%
compression in database backup file and time needed to restore, it is still
500GB... BTW, BCV restore of 1TB database takes 2-3 hours. Using litespeed,
it would take hours to backup, hours to copy, and hours to restore...
"ChrisR" wrote:
> Even if you could put it into Standby mode, you wouldnt be able to apply
> additional changes without TLog backups. I dont know if there is an option of
> new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
> "Pedja" wrote:
> > Hi,
> > We have specific problem here. We have very large database (1TB) on one
> > server, and we need to set up log shipping to another server. Problem is that
> > we don't make regular sql server backups on the source server because of
> > obvious reason (it would take too long). Therefore we cannot restore database
> > in standby mode on the standby server. The only way to do database restore in
> > our case is to use BCV software (disk subsystem on both servers is EMC), and
> > that software doesn't have option od leaving database in standby mode. My
> > question is "is there any way to put database into standby mode, regardless
> > that is hasn't been restored using sql server native restore procedure?".
> > Servers are sql server 2000, service pack 3.
> > Thanks|||We have a large database that we ship from a remote location as well. What I
did in this was to take a back up(Lite Speed) restore on stand by one time,
then continue with the logs. You do not have to do a full restore daily. When
you restore your transaction logs could you restore on stand by. (We use Lite
Speed Tranasction log as well). What we do is take a nightly backup, and copy
it over so that we have full back up for an emergency, but we never restore
them. It is harmless that backup takes long(you can schedule it for night
time). I have not noticed and significant performance trouble due to back up
in production.
> Transaction log backups are OK for this scenario. I would be able to backup
> transaction log i.e. every 2 hours, copy tl backup to the new sever, and
> restore it there. It is full database backup that I cannot apply in this
> scenario, because it would take too long. So if I could set secondary
> database which is restored using BCV (not native backup), to standby mode,
> I'd be able to apply log shipping scenario.
> Even LiteSpeed wouldn't help. This database doesn't have much text fields,
> so I don't think that compression would be that good. Even if I'd get 50%
> compression in database backup file and time needed to restore, it is still
> 500GB... BTW, BCV restore of 1TB database takes 2-3 hours. Using litespeed,
> it would take hours to backup, hours to copy, and hours to restore...
> "ChrisR" wrote:
> > Even if you could put it into Standby mode, you wouldnt be able to apply
> > additional changes without TLog backups. I dont know if there is an option of
> > new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
> >
> > "Pedja" wrote:
> >
> > > Hi,
> > > We have specific problem here. We have very large database (1TB) on one
> > > server, and we need to set up log shipping to another server. Problem is that
> > > we don't make regular sql server backups on the source server because of
> > > obvious reason (it would take too long). Therefore we cannot restore database
> > > in standby mode on the standby server. The only way to do database restore in
> > > our case is to use BCV software (disk subsystem on both servers is EMC), and
> > > that software doesn't have option od leaving database in standby mode. My
> > > question is "is there any way to put database into standby mode, regardless
> > > that is hasn't been restored using sql server native restore procedure?".
> > > Servers are sql server 2000, service pack 3.
> > > Thanks
Showing posts with label restoring. Show all posts
Showing posts with label restoring. Show all posts
Friday, March 30, 2012
log shipping without backing up and restoring the whole database
Hi,
We have specific problem here. We have very large database (1TB) on one
server, and we need to set up log shipping to another server. Problem is tha
t
we don't make regular sql server backups on the source server because of
obvious reason (it would take too long). Therefore we cannot restore databas
e
in standby mode on the standby server. The only way to do database restore i
n
our case is to use BCV software (disk subsystem on both servers is EMC), and
that software doesn't have option od leaving database in standby mode. My
question is "is there any way to put database into standby mode, regardless
that is hasn't been restored using sql server native restore procedure?".
Servers are sql server 2000, service pack 3.
ThanksEven if you could put it into Standby mode, you wouldnt be able to apply
additional changes without TLog backups. I dont know if there is an option o
f
new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed
.
"Pedja" wrote:
> Hi,
> We have specific problem here. We have very large database (1TB) on one
> server, and we need to set up log shipping to another server. Problem is t
hat
> we don't make regular sql server backups on the source server because of
> obvious reason (it would take too long). Therefore we cannot restore datab
ase
> in standby mode on the standby server. The only way to do database restore
in
> our case is to use BCV software (disk subsystem on both servers is EMC), a
nd
> that software doesn't have option od leaving database in standby mode. My
> question is "is there any way to put database into standby mode, regardles
s
> that is hasn't been restored using sql server native restore procedure?".
> Servers are sql server 2000, service pack 3.
> Thankssql
We have specific problem here. We have very large database (1TB) on one
server, and we need to set up log shipping to another server. Problem is tha
t
we don't make regular sql server backups on the source server because of
obvious reason (it would take too long). Therefore we cannot restore databas
e
in standby mode on the standby server. The only way to do database restore i
n
our case is to use BCV software (disk subsystem on both servers is EMC), and
that software doesn't have option od leaving database in standby mode. My
question is "is there any way to put database into standby mode, regardless
that is hasn't been restored using sql server native restore procedure?".
Servers are sql server 2000, service pack 3.
ThanksEven if you could put it into Standby mode, you wouldnt be able to apply
additional changes without TLog backups. I dont know if there is an option o
f
new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed
.
"Pedja" wrote:
> Hi,
> We have specific problem here. We have very large database (1TB) on one
> server, and we need to set up log shipping to another server. Problem is t
hat
> we don't make regular sql server backups on the source server because of
> obvious reason (it would take too long). Therefore we cannot restore datab
ase
> in standby mode on the standby server. The only way to do database restore
in
> our case is to use BCV software (disk subsystem on both servers is EMC), a
nd
> that software doesn't have option od leaving database in standby mode. My
> question is "is there any way to put database into standby mode, regardles
s
> that is hasn't been restored using sql server native restore procedure?".
> Servers are sql server 2000, service pack 3.
> Thankssql
log shipping without backing up and restoring the whole database
Hi,
We have specific problem here. We have very large database (1TB) on one
server, and we need to set up log shipping to another server. Problem is that
we don't make regular sql server backups on the source server because of
obvious reason (it would take too long). Therefore we cannot restore database
in standby mode on the standby server. The only way to do database restore in
our case is to use BCV software (disk subsystem on both servers is EMC), and
that software doesn't have option od leaving database in standby mode. My
question is "is there any way to put database into standby mode, regardless
that is hasn't been restored using sql server native restore procedure?".
Servers are sql server 2000, service pack 3.
Thanks
Even if you could put it into Standby mode, you wouldnt be able to apply
additional changes without TLog backups. I dont know if there is an option of
new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
"Pedja" wrote:
> Hi,
> We have specific problem here. We have very large database (1TB) on one
> server, and we need to set up log shipping to another server. Problem is that
> we don't make regular sql server backups on the source server because of
> obvious reason (it would take too long). Therefore we cannot restore database
> in standby mode on the standby server. The only way to do database restore in
> our case is to use BCV software (disk subsystem on both servers is EMC), and
> that software doesn't have option od leaving database in standby mode. My
> question is "is there any way to put database into standby mode, regardless
> that is hasn't been restored using sql server native restore procedure?".
> Servers are sql server 2000, service pack 3.
> Thanks
We have specific problem here. We have very large database (1TB) on one
server, and we need to set up log shipping to another server. Problem is that
we don't make regular sql server backups on the source server because of
obvious reason (it would take too long). Therefore we cannot restore database
in standby mode on the standby server. The only way to do database restore in
our case is to use BCV software (disk subsystem on both servers is EMC), and
that software doesn't have option od leaving database in standby mode. My
question is "is there any way to put database into standby mode, regardless
that is hasn't been restored using sql server native restore procedure?".
Servers are sql server 2000, service pack 3.
Thanks
Even if you could put it into Standby mode, you wouldnt be able to apply
additional changes without TLog backups. I dont know if there is an option of
new software or not? If so, I wrote my own Log Shipping using SQL Lite Speed.
"Pedja" wrote:
> Hi,
> We have specific problem here. We have very large database (1TB) on one
> server, and we need to set up log shipping to another server. Problem is that
> we don't make regular sql server backups on the source server because of
> obvious reason (it would take too long). Therefore we cannot restore database
> in standby mode on the standby server. The only way to do database restore in
> our case is to use BCV software (disk subsystem on both servers is EMC), and
> that software doesn't have option od leaving database in standby mode. My
> question is "is there any way to put database into standby mode, regardless
> that is hasn't been restored using sql server native restore procedure?".
> Servers are sql server 2000, service pack 3.
> Thanks
Wednesday, March 28, 2012
log shipping sql 2005 database remains in (restoring...) mode
I've been playing with the SQL 2005 log shipping and have been running into a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?
Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
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/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?
|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> 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/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?
Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
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/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?
|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> 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/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>
log shipping sql 2005 database remains in (restoring...) mode
I've been playing with the SQL 2005 log shipping and have been running into
a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard agai
n
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
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/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?|||My goal was to have a readable database on the destination side that could b
e
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (
I
never used log shipping in 2000 since we only have standard edition). I wil
l
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> 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/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>
a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard agai
n
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
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/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?|||My goal was to have a readable database on the destination side that could b
e
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (
I
never used log shipping in 2000 since we only have standard edition). I wil
l
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> 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/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>
log shipping sql 2005 database remains in (restoring...) mode
I've been playing with the SQL 2005 log shipping and have been running into a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY ={standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
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/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY => {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> 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/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> > I've been playing with the SQL 2005 log shipping and have been running
> > into a
> > few problems.
> >
> > My system is configured on a virtual server with two instances of SQL
> > 2005.
> > The OS is Windows 2003. I'm shipping logs from the default instance to the
> > named instance with the default having the primary database and the named,
> > the secondary.
> >
> > When I use the log shipping wizard, and have it do the initial restore to
> > the secondary, all appears to work well but the database remains in
> > "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> > and manually restoring the database to the secondary, I used the wizard
> > again
> > to set this up and now the Agent jobs indicate success in applying the
> > logs
> > but again, the database continues to show as (Restoring ...) in the MS
> > GUI.
> > It is indeed unavailable as you can't query it in a Query window. I tried
> > this with upgraded SQL 2000 databases and newly created SQL 2005
> > databases,
> > both with the same result.
> >
> > Has anyone run into this and can you tell me what might be happening?
>
>
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY ={standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
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/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY => {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> 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/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> > I've been playing with the SQL 2005 log shipping and have been running
> > into a
> > few problems.
> >
> > My system is configured on a virtual server with two instances of SQL
> > 2005.
> > The OS is Windows 2003. I'm shipping logs from the default instance to the
> > named instance with the default having the primary database and the named,
> > the secondary.
> >
> > When I use the log shipping wizard, and have it do the initial restore to
> > the secondary, all appears to work well but the database remains in
> > "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> > and manually restoring the database to the secondary, I used the wizard
> > again
> > to set this up and now the Agent jobs indicate success in applying the
> > logs
> > but again, the database continues to show as (Restoring ...) in the MS
> > GUI.
> > It is indeed unavailable as you can't query it in a Query window. I tried
> > this with upgraded SQL 2000 databases and newly created SQL 2005
> > databases,
> > both with the same result.
> >
> > Has anyone run into this and can you tell me what might be happening?
>
>
Friday, March 9, 2012
Log Shipping Error 4323
Hi all,
Scenario : MS Windows 2003 SP1 - MS SQL Server 2000 EE SP4
Log Shipping
My secondary server was restoring backup logs successfully, but suddenly i got the following error:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
How can I fix this situation without re create the maintenance plan ?
We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on the secondary server solved the pb (unless we had to restore the whole db, sorry I can't remember, my memory is gone... together with the customer :o).
HTH,
Vincent
Log Shipping Error 4323
Hi all,
Scenario : MS Windows 2003 SP1 - MS SQL Server 2000 EE SP4
Log Shipping
My secondary server was restoring backup logs successfully, but suddenly i got the following error:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
How can I fix this situation without re create the maintenance plan ?
We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on the secondary server solved the pb (unless we had to restore the whole db, sorry I can't remember, my memory is gone... together with the customer :o).
HTH,
Vincent
Subscribe to:
Posts (Atom)