Replication In Clustered Environement - Security Issue
Nov 16, 2007
Hello,
Not sure if this question belongs here in the Setup & Upgrade section but here is the problem.
When installing replication in a non clustered environment, the Sql replication jobs run fine with the windows login provided (this login has access to the snapshot folder and has the proper roles. All the log reader, distributer and subscriber agents work fine)
When installing replication in a windows (MS) clustered environment, the agents running under the same login and same privilages dont work. It seems like there is something wrong with the proxy account and the ability of sql to access disk resources using this account. The only workaround is to go to the agent jobs, change the login under which they work from the proxy account to an actual windows account.
Has anyone come across this issue? I am forced to use the sql agent account and running the replication agents under way more privilages than I would like to.
Is it possible for a clustered instance of SQL2012 to have 2 network names ?
Reason: I need to segregate admin access to a clustered instance so that the admins and SSMS connect via a different IP address than the application. I know I can block SSMS access via application-level firewalls, but ideally the application would connect to CLUSTER1INSTANCE01 on , say, 10.192.5.5, and the admins would connect to CLUSTER1ADMININSTANCE01 on 172.168.2.2, and they'd be the same instance, just using different names and IPs
In our lab we have 2 clustered instance of Sql server 2018R2 as follows
Virtual Server Name IP SqlVir 10.1.1.6 SqlVirDr 10.1.1.12
The Data is SqlVir is replicated manually every day to SqlVirDr.
We had to change the Virtual Server name of SqlVirDr to SqlVir so that all dot net applications accessing SqlVir could continue to access the database without changing the application string.
For that purpose I deleted the computer name SqlVir from the domain and its IP 10.1.1.6 from DNS. Then I went to the failover cluster manager of SqlVIrDr right clicked the Sql services selected the properties and changed the DNS name from SqlVirDr to SqlVir.The applications then could access the data.However when I changed the network IP address from 10.1.1.12 to 10.1.1.6 the Sql services was found to be down.
Perhaps the procedure I followed in deleting the computer name from domain and the IP from DNS was wrong.What exactly is the steps that I should follow to achieve the above objective.
We have an Sql Server 2008R2 Clustered production instance by name 'ProdVir' configured in 2 nodes(Active-passive) withWIndows Server 2008 R2. We also have another clustered instance as disaster recovery by name 'VirDr' configured again in another 2 nodes of Windows Server 2008 R2. Every day morning there is mainatenace plan which backups all the database in production and another maintenace plan in the disaster recovery server 'VirDr' which restores the backups into the VirDr instance.
I would like to know that in an eventuality of a disaster in the clustered production instance of 'ProdVir'. could we rename the the instance VirDr(meant for disaster recovery) to ProdVir and also change the Ip addresses accordingly so that the application programs do not have to change the details for the datasource in the connection strings.
We have two SQL servers, one in NY, one in Illinois, and we want to sync them. Suppose we have a T1 line as backbone, which one is a better solution for us, Clustered or SQL replication ? Your help will be greatly appreciated! Xiao
Just want to know if we can replicate data (Transactional Replication) from a clustered servers (server A and Server B are active-passive clustered running SqlServer 7) to another server C running SqlServer 7.
If yes, how to go about doing this. Any white papers, KB articles or books out there which will walk through the steps to do it.
Using SQL 2005 SP2. I have a publication that contains indexed views, and some other objects that query the indexed view using WITH (NOEXPAND). Currently replication fails because the CLUSTERED INDEX on the view is NOT replicated. I've experimented with various schema options but nothing changes. The view is replicated but not the clustered index on that view. I've seen some discussion on replicating indexed views to a table, but I would like to replicate indexed view schema fully. (Including the clustered index on that view). Is there a way to make this work?
We are running 2 SQL Server and both run in failover clustered Environment. The Problem is now we need to Replicate a Database from one Virtual SQL Sever to the other.
The Second one (clusterd environment)is stroing their database localy while the First One (clustered environment)is storing database in a shared storage. Note that Both Server are used for sperate purpose , but we now need to set replication on the Other Clustered Setup for Reporting Purpose.
Will it work if we configure replication from One SQL Server Clustered Setup to the Other Clstered Setup. If yes, then please let me know how it can be done ?
I set up replication on our servers at work to streamline some procedures we run daily/weekly on them. This copies around 15 articles from two databases on the "Master" server to another server used for execution purposes. For the most part it was a pretty straight forward task and it seemed to work nicely; but I realised after some investigation that the non-clustered indexes weren't copying over to the child server.
I set the non-clustered indexes property in the properties of the publishing articles to "True" and generated a new snapshot, this seemed to work, but I've come into work this morning to find the property has reset to "False" and I have no indexes on the table again. Why is this happening and is there any way I can resolve the matter so the indexes are copied over concurrently?
I am getting the following error during replication of Database to a client:
The schema script 'Statutes_6.dri' could not be propagated to the subscriber. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201001) Get help: http://help/MSSQL_REPL-2147201001
Invalid locale ID was specified. Please verify that the locale ID is correct and corresponding language resource has been installed. (Source: MSSQLServer, Error number: 7696) Get help: http://help/7696
Incorrect syntax near the keyword 'with'. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be terminated with a semicolon. (Source: MSSQLServer, Error number: 319)
The database is relatively small, only about 5 tables but there is a clustered Full-text Index.
My ambition is to run ASPStateInMemory with durability on, supplementing the in-memory database with an on-disk version to give session state persistence when and if the clustered instance of SQL runs into, say a network card failure and needs to fail to a partner node. I understand that DAG's are usually run between standalone instances of SQL running on different machines. But, can I combine the DAG with the FCI? Instead of using a remote standalone SQL server, can I just another instance in the same cluster?
Hello,Being a bit of a SQL Server novice, need some advice with the followingsituation.Server A and Server B have SQLServer 2000 based databases. The vendorof the application/system has implemented their own replication processto ensure the 2 databases are in sync. However, there is no clusteringwith virtual IP addresses implemented. So to an external client/db, itis 2 identical databases with the same name on 2 distinct servers.We need to develop an application that will reside on a networkedserver C and with SQLServer 2000 as well. While most of the tables inthis database are self contained, around 10 tables will have to bemirror copies of the same tables from either Server A or Server B.Question, how do we implement subscription based replication on top ofa redundant database, when no clustering is implemented? So, inessence, when Server A is alive, the database on Server C willperiodically (or on change) replicate the 10 tables from Server A. WhenServer A is not alive, it needs to do same from server B. (When bothserver A and B are alive, it is acceptable to get data from either,since they are synchronized internally).Any alternate suggestions on achieving this functionality are welcometoo. If SQL Server 2005 has some capabilities that may address thisproblem, that is a consideration as well.Thanks
I am trying to drop a primary key on column LID and then create a clustered index on a new identity column ID and then add the primary key back on the LID. I am not able to do so due the table being in replication. here is the error:
Cannot alter the table '' because it is being published for replication.
How do I get past the error and create the Clustered Index on ID column in both publisher and subscriber?
I've setup transactional replication with pull subscriptions. All my subscribers AND my publisher sits on its own domain. Is it still possible for the subscribers to access publications using Windows accounts? If so, is the setup process different from the process for setting up publishers and subscribers on the same domain?
I am being told that my SQL server can no longer use a domain account to do replication cause it is a violation of SOX codes... So here is my question to ease my pain....
I believe that I can run the SQL server service under [local system account] with no issues but what about the SQL server agent service??
It needs rights on all the servers right??
I have found where you can configure replication to use sql authentication but then I can use snapshots...
any help would be appriciated...
oh.. I use transactional and merge if that makes any difference.
How secure is the replication chanel between publisher , distributor ( these can be combined) and subscriber ? i.e. can it be encrypted, etc (moving sensitive data, ss# , $ etc...) Thank you.
What are the security groups that I would need to enable a user to use the conflict viewer and replication monitor for specific databases that are setup for merge replication? Thanks.
We are going to use SQL Sever change tracking. The problem is that some of our tables, which are to be tracked, have no primary keys. There are only unique clustered indexes. The question is what is the best way to turn on change tracking for these tables in our circumstances.
what is it supposed to mean when the sync fails and just says "a security error occurred". i verified i can view the .dll from Internet Explorer and view the share from the workstation. i gave up on the normal replication because it kept saying access was denied when it tried to download any of the files in the share... i granted access to 'everyone' for all the files and folders in that share but that didn't help.
I am using SQL server 2012 Management studio and I have some confidential data on publisher which is being replicated to subscriber and i want to revoke permission for decryption at publisher end which is only possible using Asymmetric key as it allows only private key to decry-pt the data. But problem which i am facing is,we can not take backup of asymmetric keys which i could restore at subscriber. I do not want to share the private key password with sender. Is there any way to achieve it?
I desire to have a clustered index on a column other than the Primary Key. I have a few junction tables that I may want to alter, create table, or ...
I have practiced with an example table that is not really a junction table. It is just a table I decided to use for practice. When I execute the script, it seems to do everything I expect. For instance, there are not any constraints but there are indexes. The PK is the correct column.
CREATE TABLE [dbo].[tblNotificationMgr]( [NotificationMgrKey] [int] IDENTITY(1,1) NOT NULL, [ContactKey] [int] NOT NULL, [EventTypeEnum] [tinyint] NOT NULL,
I have created two tables. table one has the following fields,
Id -> unique clustered index. table two has the following fields, Tid -> unique clustered index Id -> foreign key of table one(id).
Now I have created primary key for the table one column 'id'. It's created as "nonclustered, unique, primary key located on PRIMARY". Primary key create clustered index default. since unique clustered index existed in table one, it has created "Nonclustered primary key".
My Question is, What is the difference between "clustered, unique, primary key" and "nonclustered, unique, primary key"? Is there any performance impact between these?
I am trying out merge replication and using web synchronization.However, I am worried that I am missing something because the way it is set up, it strikes me as a bit too insecure.
According to the best practices and security articles on Technet, I am given to understand that:
The SQL Replication Listener (read: the application pool account that will be running the replisapi.dll) has to be the db_owner to both distribution and publisher and be on the PAL list. Windows authenication should be used. That means the merge agents wouldn't need to know the password for those logins.
The basic authenication can be used (with SSL) to authenicate into a Windows user account to then connect to the replisapi.dll.
Here's the rub - I assumed that all I needed was a basic no-rights user account to be then given the execute permission on the replisapi.dll & read permissions to kick off the process. When I browse to the replisapi.dll and authenicate using the no-rights user, I get the expected "SQL Server WebSync ISAPI" message. But when I then run the merge agent, it fails saying that login to the distribution failed for the no-rights user. If I use the application pool's account, then I am able to run merge agent successfully.
But that means I am now looking at storing the password to the application pool account on client. I might have had missed a crucial step to ensure that the logins to the distribution & publication databases are done using the application pool account, not the user authenticated via IIS basic authentication?
Hi there, I have a table that has an IDENTITY column and it is the PK of this table. By default SQL Server creates a unique clustered index on the PK, but this isn't what I wanted. I want to make a regular unique index on the column so I can make a clustered index on a different column.
If I try to uncheck the Clustered index option in EM I get a dialog that says "Cannot convert a clustered index to a nonclustered index using the DROP_EXISTING option.". If I simply try to delete the index I get the following "An explicit DROP INDEX is not allowed on index 'index name'. It is being used for PRIMARY KEY constraint enforcement.
So do I have to drop the PK constraint now? How does that affect all the tables that have FK relationships to this table?
I have a really super slow stored proc that does something simple. it updates a table if certain values are received.
In looking at this the matching is done on the Primary Key, which is set as a Clustered index, looking further I have another constraint, that sets the same column to a Unique, Non-Clustered.
I am not sure why this was done, but it seems to be counter productive. I have read only references to Which one is better on a primary key, but not can their be both and if it is "Smart".
I've a table with primary key defined as non-clusterd, now without dropping it can I modify the existing index to clustered through tsql as I had to write some migration script and in that script I wanna do this.
I would like to find information on Clustered and Non-clustered indexes and how B-trees are used. I know a clustered index is placed into a b-tree which makes sense for fast ordered searching. What data structure does a non-clustered index use and how? I tried to find info. on the web but couldn't get much detail...
I have a table<table1> with 804668 records primary on table1(col1,col2,col3,col4)
Have created non-clustered index on <table1>(col2,col3,col4),to solve a performance issue.(which is a join involving another table with 1.2 million records).Seems to be working great.
I want to know whether this will slow down,insert and update on the <table1>?
SELECT a.AssetGuid, a.Name, a.LocationGuid FROM Asset a WHERE a.AssociationGuid IN ( SELECT ada.DataAssociationGuid FROM AssociationDataAssociation ada WHERE ada.AssociationGuid = '568B40AD-5133-4237-9F3C-F8EA9D472662')
takes 30-60 seconds to run on my machine, due to a clustered index scan on our an index on asset [about half a million rows]. For this particular association less than 50 rows are returned.
expanding the inner select into a list of guids the query runs instantly:
SELECT a.AssetGuid, a.Name, a.LocationGuid FROM Asset a WHERE a.AssociationGuid IN ( '0F9C1654-9FAC-45FC-9997-5EBDAD21A4B4', '52C616C0-C4C5-45F4-B691-7FA83462CA34', 'C95A6669-D6D1-460A-BC2F-C0F6756A234D')
It runs instantly because of doing a clustered index seek [on the same index as the previous query] instead of a scan. The index in question IX_Asset_AssociationGuid is a nonclustered index on Asset.AssociationGuid.
The tables involved:
Asset, represents an asset. Primary key is AssetGuid, there is an index/FK on Asset.AssociationGuid. The asset table has 28 columns or so... Association, kind of like a place, associations exist in a tree where one association can contain any number of child associations. Each association has a ParentAssociationGuid pointing to its parent. Only leaf associations contain assets. AssociationDataAssociation, a table consisting of two columns, AssociationGuid, DataAssociationGuid. This is a table used to quickly find leaf associations [DataAssociationGuid] beneath a particular association [AssociationGuid]. In the above case the inner select () returns 3 rows.
I'd include .sqlplan files or screenshots, but I don't see a way to attach them.
I understand I can specify to use the index manually [and this also runs instantly], but for such a simple query it is peculiar it is necesscary. This is the query with the index specified manually:
SELECT a.AssetGuid, a.Name, a.LocationGuid FROM Asset a WITH (INDEX (IX_Asset_AssociationGuid)) WHERE a.AssociationGuid IN ( SELECT ada.DataAssociationGuid FROM AssociationDataAssociation ada WHERE ada.AssociationGuid = '568B40AD-5133-4237-9F3C-F8EA9D472662')
To repeat/clarify my question, why might this not be doing a clustered index seek with the first query?
