December 4, 2008 at 9:44 am
george sibbald (12/4/2008)
snapshot replication could work for you, but would be more complex to set up and maintain then the good old backup and restore.replication is really for scale out, where you want to spread the production load across servers. i.e the updates made on the copy would be reflected onto the primary. It does not sound like that is what you want so again backup and restore is still best for your needs.
hmmmm....yea i guess you are right...i'm fine w/ the backup/restore, but the main developer is pushing for things he doesn't know how they work - aka replication
December 4, 2008 at 9:53 am
Matt,
Sorry for the late reply to this (don't get to check the site very often, a bit busy) but something else to consider is that your transaction log files throughout the day may not result in that much data being transferred. I'm fairly certain that it is going to be significantly less than the 16GB that the database currently uses.
So, figure out what you would have in tran log files for a given period (pick busiest time of the day and sum up the size of the tran log backups) and chat with the network folks to see if you can support log shipping sending that amount of data. As already stated, I think, all of the backup compression vendors provide script helps for implementing log shipping using their syntax and you would be able to take advantage of compressed log backups thereby reducing network usage even further.
Hopefully this helps a bit.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 4, 2008 at 9:59 am
DavidB (12/4/2008)
Matt,Sorry for the late reply to this (don't get to check the site very often, a bit busy) but something else to consider is that your transaction log files throughout the day may not result in that much data being transferred. I'm fairly certain that it is going to be significantly less than the 16GB that the database currently uses.
So, figure out what you would have in tran log files for a given period (pick busiest time of the day and sum up the size of the tran log backups) and chat with the network folks to see if you can support log shipping sending that amount of data. As already stated, I think, all of the backup compression vendors provide script helps for implementing log shipping using their syntax and you would be able to take advantage of compressed log backups thereby reducing network usage even further.
Hopefully this helps a bit.
hmm now i'm really confused because I thought doing log shipping meant you had to keep the receiving database in a receiving state? therefore you couldn't use it? Also, we are looking to do this without purchasing any additional software, since its only for a small development group
December 4, 2008 at 10:13 am
You can actually use the secondary server for querying. See BOL;
You can reduce the load on your primary server by using a secondary server for read-only query processing. To do this, the secondary database must be in STANDBY mode. You will not be able to run queries if the database is in NORECOVERY mode. For more information about database modes, see RESTORE (Transact-SQL).
It would be good to read the topic on configuring Log Shipping as I believe there are some scenarios that would probably fit your situation.
Regardless, even if you had to do some neat scripting to restore the logs at intervals during the day or at night, (which can be done through the Log Shipping setup as well) you should be able to see much less network usage with the shipping of logs. Using the third party compression would just help that even further which was my point.
So, check the log sizes for the busiest time and throw it by the network admins to see if it will be ok.
Sorry for any confusion that the previous post caused... 🙂
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 4, 2008 at 10:14 am
Matt Rose (12/4/2008)
DavidB (12/4/2008)
Matt,Sorry for the late reply to this (don't get to check the site very often, a bit busy) but something else to consider is that your transaction log files throughout the day may not result in that much data being transferred. I'm fairly certain that it is going to be significantly less than the 16GB that the database currently uses.
So, figure out what you would have in tran log files for a given period (pick busiest time of the day and sum up the size of the tran log backups) and chat with the network folks to see if you can support log shipping sending that amount of data. As already stated, I think, all of the backup compression vendors provide script helps for implementing log shipping using their syntax and you would be able to take advantage of compressed log backups thereby reducing network usage even further.
Hopefully this helps a bit.
hmm now i'm really confused because I thought doing log shipping meant you had to keep the receiving database in a receiving state? therefore you couldn't use it? Also, we are looking to do this without purchasing any additional software, since its only for a small development group
correct, the best you will get with log shipping is the database in read only state.
---------------------------------------------------------------------
December 4, 2008 at 10:16 am
Matt - my mistake. Do the developers need to update the database? If so, scratch my other two posts. Ack, bad David....
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply