Getting a database on one server to match another

Sorry wasn't too clear was I.
The second server is our disaster recovery server, so we
want our second server database to be as up to date as
possible with the production database.
ta

>--Original Message--
>Hello,
>We have two servers and want out production db on server
1
>to match the production server on server 2.
>Whats the best way of doing this?
>.
>Sarah,
Hari already answered this with:
1) Log Shipping
2) Transactional replication
If the disaster recovery server does not need to be operational, then log
shipping would be good.You may also want to consider Double-Take from NSI
Software. This replicates the SQL Server data files at the block level on
disk and ensures transactional consistency.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
"Sarah" <anonymous@.discussions.microsoft.com> wrote in message
news:4c5401c42c3a$23ff0f60$a001280a@.phx.gbl...[vbcol=seagreen]
> Sorry wasn't too clear was I.
> The second server is our disaster recovery server, so we
> want our second server database to be as up to date as
> possible with the production database.
> ta
>
> 1|||Thanks Mark,
I'll have a look at transactional replication as we backup
the Production db by log files and to be honest I'm not
too sure on what will happen if we change it so it updates
asap.
Thanks for your time

>--Original Message--
>Sarah,
>Hari already answered this with:
>1) Log Shipping
>2) Transactional replication
>If the disaster recovery server does not need to be
operational, then log
>shipping would be good.You may also want to consider
Double-Take from NSI
>Software. This replicates the SQL Server data files at
the block level on
>disk and ensures transactional consistency.
>--
>Mark Allison, SQL Server MVP
>http://www.markallison.co.uk
>
>
>"Sarah" <anonymous@.discussions.microsoft.com> wrote in
message
>news:4c5401c42c3a$23ff0f60$a001280a@.phx.gbl...
server[vbcol=seagreen]
>
>.
>|||There's a web site at MS called something like "Pattern and practices". Ther
e you find a two boos on SQL
Server and high availability. You really need to go through that if you inte
nd to use replication for fail
over. There are some issues you need to plan for.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Sarah" <anonymous@.discussions.microsoft.com> wrote in message news:4ae801c42c41$337182f0$a4
01280a@.phx.gbl...[vbcol=seagreen]
> Thanks Mark,
> I'll have a look at transactional replication as we backup
> the Production db by log files and to be honest I'm not
> too sure on what will happen if we change it so it updates
> asap.
> Thanks for your time
>
>
> operational, then log
> Double-Take from NSI
> the block level on
> message
> server|||Sarah,
I really don't think transactional replication is a good high availability
solution. There are many drawbacks to using this. Do a search on the web for
high availability sql server and you should find some good information.
Kimberley Tripp did a great presentation on high availability, perhaps
search for that.
Log shipping might be a good way to go, you can have a latency of 5 minutes
with this solution.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
"Sarah" <anonymous@.discussions.microsoft.com> wrote in message
news:4ae801c42c41$337182f0$a401280a@.phx.gbl...[vbcol=seagreen]
> Thanks Mark,
> I'll have a look at transactional replication as we backup
> the Production db by log files and to be honest I'm not
> too sure on what will happen if we change it so it updates
> asap.
> Thanks for your time
>
>
> operational, then log
> Double-Take from NSI
> the block level on
> message
> server|||Thanks for your help guys

>--Original Message--
>Thanks Mark,
>I'll have a look at transactional replication as we
backup
>the Production db by log files and to be honest I'm not
>too sure on what will happen if we change it so it
updates
>asap.
>Thanks for your time
>
>
>operational, then log
>Double-Take from NSI
>the block level on
>message
we[vbcol=seagreen]
>server
>.
>