August 15, 2008 at 2:51 pm
(Revised 18 Aug 2008, 10 am EDT) Running two physically separate systems on Win Server 2003, SS2005 Standard Edition (NOT enterprise), SP 2.
I'm encountering failures in both snapshot and transactional replication. Initialization fails over what seems to be a permissions issue - trying to grant permissions to a different login specific to a single table. So, my questions are:
(1) Knowing that error message 15151 is a generic permissions error message, what additional permissions can I grant to a windows login named DRsql which belongs to system administrator group as well as all SQL Server groups, on both publisher and subscriber machines?
(2) The reports module could not be installed on the backup (Disaster Recovery) server I'm replicating to. Could the absence of that functionality (IIS has not been installed on the DR machine) be causing this problem?
August 18, 2008 at 8:29 am
(Shameless bump, adding more details)
My objective is to take a 'copy' of a production database and copy it to an offsite location several hundred miles away. My plan was to provide for 4-hour updating since we have that large a tolerance for transaction loss on the production database (NOT my decision). I'm assuming that the distance is too great to attempt a merge replication, even with a VPN. Is that a good assumption? Total user population could number several thousand, but daily transactional volume will involve many fewer users than that, but could be as high as 10,000 / day (swag). Also, the application is still growing and expanding; the unzipped backup files are smaller than 1 GB, so the physical DB is not huge.
The scenario is slightly compounded by the configuration, but for now those details are just my headache, until I get the basic replication working...
It's small comfort to know I'm not alone with this problem, posited in an even simpler configuration: http://bytes.com/forum/thread691299.html
August 18, 2008 at 10:58 am
OK. I think I solved this - by increasing the 'magical' powers of the DRsql user ID, I managed to make the assignments work. It's not clear to me, yet, which particular setting was critical - I used a shotgun approach because of a lack of time. I suspect that the answer lies in BOL, and the issue with the diagnostic is a 'policy' to leave security related error messages deliberately ambiguous - if a hacker gets in, but not all the way, the ambiguity provides a last line of defense against intrusion.... and DBAs are supposed to know this stuff anyway...
I never forget anything I remember. I just never know what I've forgotten.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply