• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 365
  • Last Modified:

Migrating Distribution DB and the subscriber db to a different SAN.

As part of SAN Migration we have planned to move the distribution db(different server)
and the subsciber db(different server)
to a different SAN. The  publisher is uneffected in this case.
Whats the best approach to perform this task without any downtime.
Just a FYI. Its an  transactional replication setup  with subscriber db  intitalized from backup.
0
venk_r
Asked:
venk_r
  • 6
  • 6
1 Solution
 
Raja Jegan RSQL Server DBA & ArchitectCommented:
Since its a SAN migration, I hope you need to have some downtime to implement this change..
Since you are trying to do it without downtime in Publisher, you can try this approach.

1. Create a new publication in Source Server
2. Configure your distribution db and Subscriber for this new publication
3. Once everything is synchronized, remove the old publication..
0
 
venk_rAuthor Commented:
Thanks for the reply.The way we have initially configured subscription is Initialize from the backup and not thru snapshot.Due to this setting I guess we have to stop other services and application pointing to the publisher and then follow the steps that you have mentioned.But I dont want to have downtime on publisher.I thought we had log retention aound 72 hrs on the replication.Can we make use of it?
0
 
Raja Jegan RSQL Server DBA & ArchitectCommented:
>> The way we have initially configured subscription is Initialize from the backup and not thru snapshot
>> I thought we had log retention aound 72 hrs on the replication.Can we make use of it?

Kindly let me know your database sizes..
If it is less, then you can re-initialize from snapshot to get it done else go for Backup
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
venk_rAuthor Commented:
The database is 600G in size and there is  particlular table which has 2 billion records in it..
0
 
Raja Jegan RSQL Server DBA & ArchitectCommented:
Are you sure it is 600GB or 600MB.
If it is 600GB, then its recommended to go with Backup
0
 
venk_rAuthor Commented:
its 600GB.
0
 
Raja Jegan RSQL Server DBA & ArchitectCommented:
Then initialize with Backup instead of snapshot..
0
 
venk_rAuthor Commented:
Since its on the same servers .It just moving the database to a different drive I thought we can handle it without creating new set of publications.Wouldnt the TLogs catch up once we bring the distributor and subscriber online?
0
 
Raja Jegan RSQL Server DBA & ArchitectCommented:
>> Since its on the same servers

This is what I have understood till now.

1. You have 600GB database replicated to another server
2. You are trying to move Distribution and Subscriber Server databases to a new SAN storage.

If I am correct, then you need to have some downtime to move your Subscriber Server databases (files) completely to the new SAN storage. Once done, you can bring Subscriber up which would automatically catch up.
This method doesn't require any downtime at the Publishing server.

Kindly confirm whether my understanding about your environment is correct or not.
0
 
venk_rAuthor Commented:
You got it right on.But how much time can the subscriber/distributor be left offline .Is there any limit?
0
 
Raja Jegan RSQL Server DBA & ArchitectCommented:
>> But how much time can the subscriber/distributor be left offline .Is there any limit?

Practically speaking there is no limit on that..
No. of transactions hit in the server when we have distributor & subscriber offline is directly proportional to the time taken to get subscriber synchronized...
0
 
venk_rAuthor Commented:
thanks
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now