I have changed the roles of primary and secondary servers due to server failure.
Can anyone advise how to revert back to previous main server? Are these any links available?See BOL topic:
How to set up and perform a log shipping role change (Transact-SQL)
In couple words - you have to set up log shipping again (move last backup from secondary to primary with stopping any activity of course on first one).|||If I set up log shipping with the old server, it becomes secondary. But I want to make my old server primary again.
Would I need to copy the db from current primary to old primary server, switch off the current server and switch on the old one?
Showing posts with label due. Show all posts
Showing posts with label due. Show all posts
Monday, March 26, 2012
Friday, March 23, 2012
Log Shipping problem
Dear Friends
I have a SQL Standard version and due to same i am not
able to do the log shipping for the database i want to
create a backup server which is only for analysis and the
same need to update only once. I can not set the
replication between the server as the Database is not
compatible for the same it is having 1024 column in many
tables.
Now What i have done is created a maintaince plan for the
backup and transactional backup in a 24 hours.
The same are replicated to the other server hard drive
with Data Replication service.
I want to create a job which will automatically restore
the transaction log on the analysis server.
Please suggest how can i achive the same. Your earlier
reply would help me a lot.
Best regards
Sharad
Take a look at the walkthrough and make sure you have only ONE database
selected at a time in the DB Maint Planner and it's in Full Recovery mode
when you have decided which one to select.
http://www.microsoft.com/technet/pro.../logship1.mspx
Hope this helps
Paul.
I have a SQL Standard version and due to same i am not
able to do the log shipping for the database i want to
create a backup server which is only for analysis and the
same need to update only once. I can not set the
replication between the server as the Database is not
compatible for the same it is having 1024 column in many
tables.
Now What i have done is created a maintaince plan for the
backup and transactional backup in a 24 hours.
The same are replicated to the other server hard drive
with Data Replication service.
I want to create a job which will automatically restore
the transaction log on the analysis server.
Please suggest how can i achive the same. Your earlier
reply would help me a lot.
Best regards
Sharad
Take a look at the walkthrough and make sure you have only ONE database
selected at a time in the DB Maint Planner and it's in Full Recovery mode
when you have decided which one to select.
http://www.microsoft.com/technet/pro.../logship1.mspx
Hope this helps
Paul.
Monday, March 19, 2012
Log shipping maintenance on secondary server
Due to a large input on the primary server, one of our tables had grown
enormously. With the right commands (delete, dbcc shrinkdatabase), we managed
to shrink this primary server down to normal proportions. Is there a way to
do this also for the secondary server?
As it is log shipped you can't.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"JohnPaw" <JohnPaw@.discussions.microsoft.com> wrote in message
news:C2CCBFDF-6C2C-4D62-B5D0-5224E7E5CB59@.microsoft.com...
> Due to a large input on the primary server, one of our tables had grown
> enormously. With the right commands (delete, dbcc shrinkdatabase), we
> managed
> to shrink this primary server down to normal proportions. Is there a way
> to
> do this also for the secondary server?
>
|||That database cannot be shrunk at all? Just delete log shipping and start all
over again?
|||I don't believe it can as it will break the log shipping chain. Give it a
try and see what happens.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"JohnPaw" <JohnPaw@.discussions.microsoft.com> wrote in message
news:2CF05F31-AC52-48D2-93BE-661C783BDBA2@.microsoft.com...
> That database cannot be shrunk at all? Just delete log shipping and start
> all
> over again?
>
enormously. With the right commands (delete, dbcc shrinkdatabase), we managed
to shrink this primary server down to normal proportions. Is there a way to
do this also for the secondary server?
As it is log shipped you can't.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"JohnPaw" <JohnPaw@.discussions.microsoft.com> wrote in message
news:C2CCBFDF-6C2C-4D62-B5D0-5224E7E5CB59@.microsoft.com...
> Due to a large input on the primary server, one of our tables had grown
> enormously. With the right commands (delete, dbcc shrinkdatabase), we
> managed
> to shrink this primary server down to normal proportions. Is there a way
> to
> do this also for the secondary server?
>
|||That database cannot be shrunk at all? Just delete log shipping and start all
over again?
|||I don't believe it can as it will break the log shipping chain. Give it a
try and see what happens.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"JohnPaw" <JohnPaw@.discussions.microsoft.com> wrote in message
news:2CF05F31-AC52-48D2-93BE-661C783BDBA2@.microsoft.com...
> That database cannot be shrunk at all? Just delete log shipping and start
> all
> over again?
>
Wednesday, March 7, 2012
Log Shipping Concern
My department is thinking of implementing Log Shipping for a database. We
have a concern that, due to the nature of replication via log files, some
transactions may not execute properly on the secondary server and when this
occurs we will have essentially non-matching databases. Is this concern a
real issue and if so, how are such issues resolved?
Right now our situation allows us to dump and restore the database at any
time and take it offline if we have to. This dump and restore availability
ensures that we have two exact copies of the database with identical
footprints. Basically our concern is that we want to be assured an equal
concurrecy with log shipping.
Can anybody provide any insight?
Thanks,
Jeff
PS. I was not sure which group to post this in (I posted the same message
in this and in .Replication). Which group do Log Shipping questions belong
in?Log Shipping works but can be a pain in the neck.
the biggest problem we ran into was the occurence of "Non-Logged" Operations
in production.
this breaks log shipping quicker than you can blink.
Cheers,
Greg Jackson
Portland, OR|||Log shipping is mainly used for maintaining standby
Servers.
If you want to do logshipping for just only one database
in a server, make sure you are taking a right decision.
Compare the pros & cons of Replication and Log Shipping
and see whether log shipping is your right choice over
Replication. If you are more concerned about data
concurrency, check whether Replication solves your purpose.
Once log shipping has been implemented, it is relatively
easy to maintain. If Logshipping is implemented properly,
usually there wont be much issues.Its very robust.
I have encountered only the issues which is explained in
the articles below.
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/prodtechnol/sql/reskit/sql2000/part4/c1361.asp
This link may help you get better idea of Log shipping.
This is a webcast.
http://support.microsoft.com/default.aspx?kbid=821786
The issue you have mentioned about the non-matching
databases, I have not come across in my vast experience in
Logshipping or Replication. I think that,if the databases
on publisher and subscriber are in sync with every aspects
(contraints,data..), then this will not occur.
If I have understand correctly, then Replication is the
best and suits your purpose.
Hope this gives you some idea to start with.
SQLVarad (MCDBA-1999,MCSE-1999)
>--Original Message--
>My department is thinking of implementing Log Shipping
for a database. We
>have a concern that, due to the nature of replication via
log files, some
>transactions may not execute properly on the secondary
server and when this
>occurs we will have essentially non-matching databases.
Is this concern a
>real issue and if so, how are such issues resolved?
>Right now our situation allows us to dump and restore the
database at any
>time and take it offline if we have to. This dump and
restore availability
>ensures that we have two exact copies of the database
with identical
>footprints. Basically our concern is that we want to be
assured an equal
>concurrecy with log shipping.
>Can anybody provide any insight?
>Thanks,
>Jeff
>PS. I was not sure which group to post this in (I posted
the same message
>in this and in .Replication). Which group do Log
Shipping questions belong
>in?
>
>.
>|||>the biggest problem we ran into was the occurence of "Non-
Logged" Operations
>in production.
>this breaks log shipping quicker than you can blink.
If you are in a production environment, you shouldn't be
doing non-logged operations. And under SQL 2K, this
really for the most part isn't possible. You use Full or
Bulk-Logged, and log shipping works. Simple prevents you
from making tran log backups at all.
The non-logged issue was more of a problem in SQL 7 and
earlier.
have a concern that, due to the nature of replication via log files, some
transactions may not execute properly on the secondary server and when this
occurs we will have essentially non-matching databases. Is this concern a
real issue and if so, how are such issues resolved?
Right now our situation allows us to dump and restore the database at any
time and take it offline if we have to. This dump and restore availability
ensures that we have two exact copies of the database with identical
footprints. Basically our concern is that we want to be assured an equal
concurrecy with log shipping.
Can anybody provide any insight?
Thanks,
Jeff
PS. I was not sure which group to post this in (I posted the same message
in this and in .Replication). Which group do Log Shipping questions belong
in?Log Shipping works but can be a pain in the neck.
the biggest problem we ran into was the occurence of "Non-Logged" Operations
in production.
this breaks log shipping quicker than you can blink.
Cheers,
Greg Jackson
Portland, OR|||Log shipping is mainly used for maintaining standby
Servers.
If you want to do logshipping for just only one database
in a server, make sure you are taking a right decision.
Compare the pros & cons of Replication and Log Shipping
and see whether log shipping is your right choice over
Replication. If you are more concerned about data
concurrency, check whether Replication solves your purpose.
Once log shipping has been implemented, it is relatively
easy to maintain. If Logshipping is implemented properly,
usually there wont be much issues.Its very robust.
I have encountered only the issues which is explained in
the articles below.
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/prodtechnol/sql/reskit/sql2000/part4/c1361.asp
This link may help you get better idea of Log shipping.
This is a webcast.
http://support.microsoft.com/default.aspx?kbid=821786
The issue you have mentioned about the non-matching
databases, I have not come across in my vast experience in
Logshipping or Replication. I think that,if the databases
on publisher and subscriber are in sync with every aspects
(contraints,data..), then this will not occur.
If I have understand correctly, then Replication is the
best and suits your purpose.
Hope this gives you some idea to start with.
SQLVarad (MCDBA-1999,MCSE-1999)
>--Original Message--
>My department is thinking of implementing Log Shipping
for a database. We
>have a concern that, due to the nature of replication via
log files, some
>transactions may not execute properly on the secondary
server and when this
>occurs we will have essentially non-matching databases.
Is this concern a
>real issue and if so, how are such issues resolved?
>Right now our situation allows us to dump and restore the
database at any
>time and take it offline if we have to. This dump and
restore availability
>ensures that we have two exact copies of the database
with identical
>footprints. Basically our concern is that we want to be
assured an equal
>concurrecy with log shipping.
>Can anybody provide any insight?
>Thanks,
>Jeff
>PS. I was not sure which group to post this in (I posted
the same message
>in this and in .Replication). Which group do Log
Shipping questions belong
>in?
>
>.
>|||>the biggest problem we ran into was the occurence of "Non-
Logged" Operations
>in production.
>this breaks log shipping quicker than you can blink.
If you are in a production environment, you shouldn't be
doing non-logged operations. And under SQL 2K, this
really for the most part isn't possible. You use Full or
Bulk-Logged, and log shipping works. Simple prevents you
from making tran log backups at all.
The non-logged issue was more of a problem in SQL 7 and
earlier.
Subscribe to:
Posts (Atom)