February 3, 2009 at 9:21 am
I'm trying to configure transactional replication between two back-end SSQL2K5 servers, but some of the tables won't replicate because they do not have primary keys defined.
Was following this article...
How do I Configure transactional replication between two SQL Server 2005 systems?
http://blogs.techrepublic.com.com/howdoi/?p=123\
In particular, I’m running into an issue when configuring the SQL transactional publications for replication. I have selected to replicate from the WSS_Content_Intranet80_MOSS2K7 SharePoint content database on our first MOSS SQL server to the secondary/back-end MOSS SQL server, but it is saying that some of the required tables won’t replicate because they do not have primary keys defined.
How can we get the required tables and objects to replicate? We can’t be expected to define primary keys for these tables in the SharePoint content database, and for all the other databases we want to replicate, can we?
Thanks.
February 3, 2009 at 9:45 am
Instead of replication, you may want to look at database mirrioring. Personally, I don't think I'd want to go into a SharePoint database and start adding primary keys where they don't exist. I'd be concerned about breaking something in WSS/MOSS.
February 3, 2009 at 9:51 am
I agree about not wanting to modify/add primary keys for fear it might mess WSS/MOSS up. Which brings me to my next post (my attempt at setting up database mirroring).
Should I use SS2K5 database mirroring in a production environment?
http://qa.sqlservercentral.com/Forums/Topic649007-291-1.aspx
February 3, 2009 at 10:05 am
Been there... I have used logshipping instead of DB Mirroring.
* Noel
February 3, 2009 at 10:05 am
Why are you replicating the sharepoint databases? What's the end goal?
Should I use SS2K5 database mirroring in a production environment?
Why not? What's your concern?
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 3, 2009 at 10:15 am
The end goal is to achieve 100% uptime (or as close to that as possible), as we have firm-wide applications that were developed in SharePoint, that need to be up and running all the time. We currently only have one front-end SharePoint (SP) server, but we have two back-end SQL servers. So, for failover-redundancy purposes, I want to replicate or mirror the primary SharePoint databases to the secondary failover database server. Then if the primary dbase server goes down, and admin would manually adjust the primary role to the secondary sql server.
February 3, 2009 at 11:49 am
The you want mirroring, not replication. Replication is for when you need a reporting database or similar. It does create a copy, but the failover's not immediate and the fail back requires a lot of work.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 3, 2009 at 12:07 pm
GilaMonster (2/3/2009)
The you want mirroring, not replication. Replication is for when you need a reporting database or similar. It does create a copy, but the failover's not immediate and the fail back requires a lot of work.
It depends!
We use replication ( a lot) and our apps use DNS Aliases to connect to the servers.
Failover just mean a DNS Alias change!
Fail back with "peer-to-peer" is a non issue 😉
* Noel
February 3, 2009 at 12:16 pm
noeld (2/3/2009)
Fail back with "peer-to-peer" is a non issue 😉
True. I was thinking Transactional.
I keep forgetting about peer-to-peer because I've never experimented with it.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply