|
Home > Archive > Microsoft Content Management Server > April 2004 > Two MCMS 20002 instances with one database server
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Two MCMS 20002 instances with one database server
|
|
| Robin 2004-04-29, 11:36 am |
| Hi,
at this moment we have one authoring server and one run server with
MCMS 2002. Both databases are on the same server and the content is
copied from one database to the other by using a programmed
deploymentservice, using the MCMS API.
Since there is no advantage in having two databases on the same server
(if it crashes both are gone anyway). I was wondering if it is
possible to point both MCMS instances to one and the same database on
the authoring server by setting the database in the MCMS DCA.
Does it have any drawbacks of some kind? CPU, Memory, Cache, etc.?
Gr.,
Robin
| |
| Paul Chan[MSFT] 2004-04-30, 9:36 am |
| If you want to run the production server on the same database as the
authoring server, you need to run DCA from the production server so as to
associate CMS from the production server to the authoring database. Since
you're running live authoring directly to the production database (well,
the previous authoring database will become a production database as the
production server is sharing it with authoring), I'll suggest you to
synchronize both CMS machine key (use the
<Cms_Root>\Server\bin\ManageKey.exe utility to export a key file from one
machine, and then import that file onto the other machine), which requires
a reboot.
The draw back is that you risk the chance of any errors in the posting will
show up immediately (after it's approved) because there's no buffer zone
(for testing/QA). CPU utilization on the CMS servers I can imagine that
it'll be the same. However, it is possible that the production server
response time will degrade (slightly) during an authoring session from the
authoring server, just because the additional database traffic. This could
be the major performance draw back I can see, but it depends on how much
authoring traffic your site has. A test will be nice.
But you might possibly gain performance by not running Site Deployment
script (so as to minimize database object being locked during deployment,
and re-caching). However, you lost the ability to schedule update time
after business hours (because you're using live authoring which the control
is up to the users).
So, it's really up to you to decide the pros and cons and which way to fit
your environment.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2001 Microsoft Corporation. All rights
reserved.
|
|
|
|
|