mirrored sql servers

Hello:
I have 2 MS SQL Servers 2000 Developer edition.
Both have same settings and databases. I'd like to have them as mirrored
servers - all transaction on one server must be performed on the other
automatically. More than that I'd like to get possible if something happened
to one server, all transactions will be performed on another one.
Please, give me a hint how to do that.

Thanks,
GBGB (v7v1k3@.hotmail.com) writes:
> I have 2 MS SQL Servers 2000 Developer edition.
> Both have same settings and databases. I'd like to have them as mirrored
> servers - all transaction on one server must be performed on the other
> automatically. More than that I'd like to get possible if something
> happened to one server, all transactions will be performed on another
> one.

Symmetric or one-way? If one server is a main server, and the other is a
standby server, you can use either log shipping or transactional
replication. Log shipping is easier to manage, as transactional
replication leaves its mark on the source database. On the other hand,
the standby server will not be accessible each time a log is applied,
and the lag time is longer.

If it is symmetric, that actions are to be replicated in both directions,
then you may want to look into merge replication. But this sounds anything
about trivial to me. What about if the same row was updated in both
databases? Who wins?

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||The only purpose I have is to have a "backup" server to be ready
to substitute main server at any time with recent data in it
and "seamless" switching in production mode.

"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns970419D43A88Yazorman@.127.0.0.1...
> GB (v7v1k3@.hotmail.com) writes:
> > I have 2 MS SQL Servers 2000 Developer edition.
> > Both have same settings and databases. I'd like to have them as mirrored
> > servers - all transaction on one server must be performed on the other
> > automatically. More than that I'd like to get possible if something
> > happened to one server, all transactions will be performed on another
> > one.
> Symmetric or one-way? If one server is a main server, and the other is a
> standby server, you can use either log shipping or transactional
> replication. Log shipping is easier to manage, as transactional
> replication leaves its mark on the source database. On the other hand,
> the standby server will not be accessible each time a log is applied,
> and the lag time is longer.
> If it is symmetric, that actions are to be replicated in both directions,
> then you may want to look into merge replication. But this sounds anything
> about trivial to me. What about if the same row was updated in both
> databases? Who wins?
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp|||GB (v7v1k3@.hotmail.com) writes:
> The only purpose I have is to have a "backup" server to be ready
> to substitute main server at any time with recent data in it
> and "seamless" switching in production mode.

OK. The I would suggest log shipping.

However, you cannot really switch into real production mode with
Developer Edition, as you don't have a license for it. But it is
of course, perfectly OK to set up log shipping to learn how to
use it for a production scenario.

Oh, I should add that once you come to production, you may only
have Standard or Workgroup Edition. Log Shipping is included in
Enterprise Edition only, so for these edition replication is about
the only option.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||In message <Xns97047DCD3077Yazorman@.127.0.0.1>, Erland Sommarskog
<esquel@.sommarskog.se> writes
>GB (v7v1k3@.hotmail.com) writes:
>> The only purpose I have is to have a "backup" server to be ready
>> to substitute main server at any time with recent data in it
>> and "seamless" switching in production mode.
>OK. The I would suggest log shipping.
>However, you cannot really switch into real production mode with
>Developer Edition, as you don't have a license for it. But it is
>of course, perfectly OK to set up log shipping to learn how to
>use it for a production scenario.
>Oh, I should add that once you come to production, you may only
>have Standard or Workgroup Edition. Log Shipping is included in
>Enterprise Edition only, so for these edition replication is about
>the only option.

If GB wants clustering and failover I think he will need the enterprise
edition.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.|||Bernard Peek (bap@.shrdlu.com) writes:
> If GB wants clustering and failover I think he will need the enterprise
> edition.

That is correct. (OK, since Developer Edition has all that Enterprise
Edition has, you can put that on a cluster. But if you put Developer
Edition on a cluster, then your hardware budget for your development
environment is quite excessive.)

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||"Bernard Peek" <bap@.shrdlu.com> wrote in message
news:ahtXDqTk30aDFwG3@.shrdlu.com...
> In message <Xns97047DCD3077Yazorman@.127.0.0.1>, Erland Sommarskog
> <esquel@.sommarskog.se> writes
> >GB (v7v1k3@.hotmail.com) writes:
> >> The only purpose I have is to have a "backup" server to be ready
> >> to substitute main server at any time with recent data in it
> >> and "seamless" switching in production mode.
> >OK. The I would suggest log shipping.
> >However, you cannot really switch into real production mode with
> >Developer Edition, as you don't have a license for it. But it is
> >of course, perfectly OK to set up log shipping to learn how to
> >use it for a production scenario.
> >Oh, I should add that once you come to production, you may only
> >have Standard or Workgroup Edition. Log Shipping is included in
> >Enterprise Edition only, so for these edition replication is about
> >the only option.
> If GB wants clustering and failover I think he will need the enterprise
> edition.

SQL Server 2005 will be released with DB mirroring, though in a "beta form".

He may want to look at this.

> --
> Bernard Peek
> London, UK. DBA, Manager, Trainer & Author.

Min & Max Memory in 2005

Is there a best practice for setting the Minimum and Maximum Memory settings
in SQL Server 2005 on a dedicated SQL Server machine. With SQL Server 2000
we set the minimum and maximum memory to be the same value on our large
clustered SQL Server machines. This seemed to work very well. Is the same
true for 2005?My experience so far has been you should at least set the max server
memory if you are beyond 2GB range, regardless of x86 or x64.
Note...if you are running x64 and have more than once instance, you
will also should to set it for ALL instances if you have more than one
on the box (or cluster in an active/active situation)...otherwise, the
most greedy instance wins out, creating memory pressure on the OS as
well...or so it goes from my experience. SQL will give up memory when
it recieves the out memory messages from the OS, but in the few times
I tested it during our initial deployment, the memory starvation of
one instance created massive slow downs in performance.
On Jun 15, 9:44 am, "Cgal" <cgalle...@.newsgroups.nospam> wrote:
> Is there a best practice for setting the Minimum and Maximum Memory settings
> in SQL Server 2005 on a dedicated SQL Server machine. With SQL Server 2000
> we set the minimum and maximum memory to be the same value on our large
> clustered SQL Server machines. This seemed to work very well. Is the same
> true for 2005?|||Setting the min and max to the same basically fixes your memory at that
point and doesn't leave room for the OS to share if needed. In general leave
the min at 0 (default) and set the MAX to a value to always leave some for
the OS. Most systems will work fine with MAX at the default if you are not
using AWE but there may be times when you simply want to leave x amount of
memory for the OS and any other apps running on the server. If you are using
AWE and 32 bit you must set it to some value less than MAX because it is not
dynamic and will starve the OS.How much you leave depends on how much you
have and what you are doing.
--
Andrew J. Kelly SQL MVP
"Cgal" <cgallelli@.newsgroups.nospam> wrote in message
news:%23AqYlN1rHHA.4768@.TK2MSFTNGP02.phx.gbl...
> Is there a best practice for setting the Minimum and Maximum Memory
> settings in SQL Server 2005 on a dedicated SQL Server machine. With SQL
> Server 2000 we set the minimum and maximum memory to be the same value on
> our large clustered SQL Server machines. This seemed to work very well.
> Is the same true for 2005?
>