Transactional Replication: Non-Clustered Indexes not copying.

Hello,
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?
Thanks in advance for your advice.
JB

I actually solved this.
You can use a post-replication SQL script to create the indexes. Whatever articles you're publishing open up the indexes drop down list of the article in object explorer, right-click on an index and hover over Script Index as, then Create-to, then click
New Query Window editor.
Up will pop up a new query window with the resulting index. Work your way through all the indexes on all the articles of the publication, copy and pasting just the create index line and below of each script, pull them all together into one query window.
Once you're done find a safe folder somewhere on your harddrive and save the SQL query as an .sql file with a sensible name.
Right click on the publication and goto properties. Click on the "Snapshot" tab, in there; there should be a section saying "Run additional scripts". Choose the browse button next to "After applying the Snapshot; execute this script:"
Navigate to your script file and choose it. Once done click ok and it'll prompt you that something has changed and if you'd like to generate a new snapshot, make sure you do or it won't work.
That's it, you'll find once the publication has bulk copied over the the subscriptions successfully there are non clustered indexes on the tables. Pretty simple!

Similar Messages

Non Clustered Indexing not working for SQL server 2005

I have create two non clustered index on two particular tables. Now the problem is its working fine..but after restarting my server its working stop and then again I have to delete that index and recreate it.

try these links
http://blog.sqlauthority.com/2009/02/07/sql-server-introduction-to-force-index-query-hints-index-hint/
http://blog.sqlauthority.com/2009/02/08/sql-server-introduction-to-force-index-query-hints-index-hint-part2/
http://www.brentozar.com/archive/2013/10/index-hints-helpful-or-harmful/
Hope it Helps!!

Transactional Replication Not replicating non-clustered Indexes

Hi
I have created a transactional replication.I am sure that I have configured it to replicate Non-Clustered indexes,
but It does not do so.
I tried several times to reinitialize the subscription,but still no luck.
Regards

It is True for sure.
But the problem is solved.I had to wait until the Initialize process get completed.
But I am sure that this problem happened before.Sometimes it works fine but sometimes not.
Hi ArashMasroor,
According to your description, it seems that you encounter the issue that non-clustered indexes property is reset to “False” sometimes.
To work around this issue, you can use a post-replication SQL script to create the indexes. Whatever articles you’re publishing open up the indexes drop down list of the article in object explorer, right-click on an index and levitate over Script Index as,
then Create-to, then click New Query Window editor.
Up will pop up a new query window with the resulting index. Work your way through all the indexes on all the articles of the publication, copy and pasting just the create index line and below of each script, pull them all together into one query window.
Once you’re done find a safe folder somewhere on your hard drive and save the SQL query as an .sql file with a sensible name. Then you can execute this script after applying the Snapshot. For more details, please review this
blog.
There is also a similar thread for your reference.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b0f3870d-1a65-4384-a17b-96825ec5f098/transactional-replication-nonclustered-indexes-not-copying?forum=sqlreplication
Thanks,
Lydia Zhang
Lydia Zhang
TechNet Community Support

What is RID in non clustered index and its use

Hi All,
I need help regarding following articles on sql server
1) what is RID in non clustered index and its use.
2) What is Physical and virtual address space. Difference in 32 bit vs 64 bit Virtual address space
Regards
Rahul

Next time Please ask single question in a thread you will get better response.
1. RID is location of heap. When you create Non clustered index on heap and
lookup happens to get extra records RID is used to locate the records. RID is basically Row ID. This is basic definition for you. Please read
this Thread for more details
2. I have not heard of Physical address space. I Know Virtual address space( VAS)
VAS is simple terms is amount of memory( virtual ) 'visible' to a process, a process can be SQL Server process or windows process. It theoretically depends on architecture of Operating System. 32 bit OS will have maximum range of 4 G VAS, it's calculated
like a process ruining on 32 bit system can address max up to 2^32 locations ( which is equivalent to 4 G). Similarly for 64 bit max VAS will be 2^64 which is theoretically infinite. To make things feasible maximum VAS for 64 bit system is kept to 8 TB. Now
VAS acts as layer of abstraction an intermediate .Instead of all request directly mapping to physical memory it first maps to VAS and then mapped to physical memory so that it can manage request for memory in more coordinated fashion than allowing process
to do it ,if not it will soon cause memory crunch.Any process when created on windows will see virtual memory according to its VAS limit.
Please read
This Article for detailed information
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
My Technet Wiki Article
MVP

Space occupied by clustered index Vs non-clustered index

I am trying to understand the indexes. Does clustered index occupy more space than a non-clustered index because it carries the information about rest of the other columns also. Could you guys please help me understand this. Thanks in advance.
svk

Hi czarvk,
Clustered index in SQL Server takes up more space than non-clustered indexes.
Clustered index arranges the way records are stored in a table putting them in order (key, value), all the data are sorted on the values of the index.
A non-clustered index is a completely different object in a table, containing only a subset of columns and a row locator to the table’s rows or to the clustered index’s key.
So clustered index in SQL Server takes up more space than non-clustered indexes.
If you have any question, please feel free to let me know.
Regards,
Donghui Li

Transaction replication DML [update] operation not allowing

We are configuration the transaction replication from production to DR site, while I am trying to perform the DML [update] operation in publication database, DML [update] operation not allowing.
Note: How we can perform DML [update] operation in publication database.

Hi MSDN_12345,
According to your description, after configuring
SQL Server transaction replication between two different Servers successfully. We can execute the update commands on Publisher Server. In theory, after updating the publication database, we also sync the data to the subscription database.
For more information, see:
http://msdn.microsoft.com/en-us/library/ms152754.aspx
So as other post, please post more details for analysis.
If the update command was not allowed to perform, we need to verify if your account has the related permission on the publication table, such as update permission, select permission and so on. Usually, the members of the sysadmin fixed server
role, the db_owner and db_datawriter fixed database roles, have update permissions.
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

Impact of creating a non-clusterd index on a huge transaction table?

Hello Everyone,
We have a transaction table containing 10 million records and everyday a million records will be inserted. We don’t have any clustered index on this table as this is a transaction table (more than 10 columns to uniquely identify a row). We
do have some SPs which in turn some reports getting generated using this table. In order to improve the performance of an SP, we created a non-clustered index on this table and we found a huge performance gain.
Here comes my question - will this (creation of non-clustered index) impacts my table data load performance or other reports generation?
Any suggestions will be appreciated.
Many Thanks!
Rajasekhar.

Hello Rajasekhar,
First identify this table and corresponding columns usage. Through SP_depends system procedure you can identify this table dependencies.
Then look at complex queries and it's execution plans. You can get an output recommendations of appropriate missing indexes.
Now you can try to create appropriate indexes. Always I suggest you to limit the index count if you are inserting/updating large volume records. Also if possible create clustered index.
One more option, you can horizontally partitioned the table and move data to multiple filegroups. Based of range of data your query performance also improve a lot.
To apply partition for existing table, you should take backup and recreate from scartch.
Check this link : http://www.mssqltips.com/sqlservertip/2888/how-to-partition-an-existing-sql-server-table/
Best Regards,
Ashokkumar.
Ashokkumar

Transactional replication from a failover cluster instance to a SQL Server Express DB

Hello,
I have been poking around on Google trying to understand if there are any gotchas in configuring transactional replication on a instance DB of a failover cluster, to a SQL Server Express DB. Also, this client would like to replicate a set of tables between
two instances DB's which both reside on nodes of the cluster.
Everything I've read suggests there is no problem using transactional replication on clustered instance as long as you use a shared snapshot folder. I still have some concerns:
1) Should the distributor need to live on a separate instance?
2) What happens in the event of an automatic, or manual failover of a publisher, especially if the distributor does not need to live on a separate instance? I know that when a failover occurs, all jobs in progress are stopped and this seems like a recipe for
inconsistency between the publisher and subscriber.
There is a paramount concern, that this particular client won't have staff on hand to troubleshoot replication if there are problems, hence my hesitancy to implement a solution that relies on it.
Thanks in advance.

1) Should the distributor need to live on a separate instance?
Answer: It is recommended to configure the distributor on the different server, but it also be configured on Publisher/subscriber server. (Subscriber in our case is not possible as its a Express edition)
2) What happens in the event of an automatic, or manual failover of a publisher, especially if the distributor does not need to live on a separate instance? I know that when a failover occurs, all jobs in progress are stopped and this seems like a recipe for
inconsistency between the publisher and subscriber. There is a paramount concern, that this particular client won't have staff on hand to troubleshoot replication if there are problems, hence my hesitancy to implement a solution that relies on it.
Answer: If you configure both publisher and distributor on the same server and the SQL instance is failed over, the data synchronization/replication is suspended till the instance comes online.
Once the instance is up,all the replication jobs will start again and it will continue to synchronize the data to subscriber. No manual intervention is required.

How do I set access 2002 Upsizing Wizard to create clustered-index on SQL 2005

Here is an extract from the Acc2Sql2.doc >>
By default, the Upsizing Wizard
transfers all indexes as nonclustered indexes. You can modify the Upsizing
Wizard to transfer the primary key index to a clustered index. To make this
change, start Microsoft Access and open the upsizing wizard library database.
For Microsoft Access 95, the filename is Wzcs.mda. For Microsoft Access 97, the
filename is Wzcs97.mda. When the database is open, click the Modules tab and open the
UT_ModUserConstants module. Search down to the UT_CLUSTERED constant. Change
the default value from False to True.
<<< end quote
Question: I am using ACCESS 2002 upsize wizard, I searched my computer for *.mda and could not find any wzcs*.mda. How do I set it so that it creates clustered-index instead of non-clustered-index?

Hi,
This question is not related to the forum. This is a question regarding MS-ACCESS.
[Personal Site] [Blog] [Facebook]

How to create clustered index?

When working with Relational model I do not see how to make index clustered? All indexes (as well as primary keys) are created non clustered so far...

In an Oracle Physical Model, you can create a Cluster and create an Index on that ClusterI am designing for SQL Server, not for Oracle. So Oracle specific approaches would not help me.
Even for the Oracle (which I do not know much but I can guess) I think that this is not what I was asking for. I simply need to create a clustered index, not to include column into some cluster. In other words I need that generated DDL looks like
create clustered index...
Now it always looks like
create nonclustered index...

Large tables without clustered indexes -- a bad idea, or ok?

We have several large tables that don't have clustered indexes, but do have primary keys and assorted other indexes. We're seeing issues that look like they are related to statistics even though there is a nightly update statistics job.
So my question is, does the existence of a clustered index impact other indexes or the update statistics process? Are our tables ok the way they are?
Adding clustered indexes would be a big project for non-development-related reasons so I would need to have good reasons to advocate for this.

RSingh,
"By default" is a confusing word here. If you do it with WIZARD, I agree. But with T-SQL,there is no space for by default, it can be anything.
I agree that I assumed here as I wont do much things with wizard. :)
Try the below:
--Here by default, its non-clustered
create table Test_table(Col1 int , Col2 int not null )
Create clustered index IX__Test_Table on Test_Table (Col1)
Alter table test_Table
Add Constraint PK_testTable
Primary Key (Col2);
Drop table test_table
--Here by default, its clustered
create table Test_table(Col1 int , Col2 int not null Primary key)
Create index IX__Test_Table on Test_Table (Col1)
Drop table test_table
Neither the word "By Default" is a confusing word nor it happens only in WIZARD. Let me clarify below. I said "When a primary key constraint is created it creates a unique clustered index by default". Run the below DDL and check whether
a clustered index is created or not. i.e
CREATE TABLE Persons
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
Regards, RSingh
That did not really make any sense to my context as I am NOT against that it will create Clustered index, In fact, my code says the same. My point is only "By default" is confusing.
Let me explain, what I mean "By default"....
Create index IX_Indexname on Tablename(Colname)
The above will create "non clustered index" BY DEFAULT. Any situation, the above would create only non-clustered irrespective of other indexes present in the table.
Hope the above is clear. May be its my way looking at "BY DEFAULT".

Transactional replication very slow with indexes on Subscriber table

I have setup Transactional Replication for one of our databases where one table with about 5mln records is replicated to a Subsriber database. With every replication about 500-600.000 changed records are send to the Subscriber.
Since one month I see very strange behaviour when I add about 10 indexes to the Subscriber table. As soon as I have added the indexes replication speed becomes extremely slow (almost 3 hours for 600k records). As soon as I remove the indexes the replication
is again very fast, about 3 minutes for the same amount of records.
I've searched a lot on the internet to solve this issue but can't find any explaination for this strange behaviour after adding the indexes. As far as I know it doesn't have to be a problem to add indexes to a Subscriber table, and it hasn't been before on
another replication configuration we use.
Some information from the Replication Log:
With indexes on the Subscriber table
Total Run Time (ms) : 9589938 Total Work Time : 9586782
Total Num Trans : 3 Num Trans/Sec : 0.00
Total Num Cmds : 616245 Num Cmds/Sec : 64.28
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 9580752
Time Spent on Commits (ms): 2687 Commits/Sec : 0.00
Time to Apply Cmds (ms) : 9586782 Cmds/Sec : 64.28
Time Cmd Queue Empty (ms) : 5499 Empty Q Waits > 10ms: 172
Total Time Request Blk(ms): 5499
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 10378 Cmds/Sec : 59379.94
Time Cmd Queue Full (ms) : 9577919 Full Q Waits > 10ms : 6072
Without indexes on the Subscriber table
Total Run Time (ms) : 89282 Total Work Time : 88891
Total Num Trans : 3 Num Trans/Sec : 0.03
Total Num Cmds : 437324 Num Cmds/Sec : 4919.78
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 86298
Time Spent on Commits (ms): 282 Commits/Sec : 0.03
Time to Apply Cmds (ms) : 88891 Cmds/Sec : 4919.78
Time Cmd Queue Empty (ms) : 1827 Empty Q Waits > 10ms: 113
Total Time Request Blk(ms): 1827
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 2812 Cmds/Sec : 155520.63
Time Cmd Queue Full (ms) : 86032 Full Q Waits > 10ms : 4026
Can someone please help me with this issue? Any ideas?
Pim

Hi Megens:
Insert statement might be slow with not only indexes and few others things too
0) SQL DB Blocking during inserts
1) If any insert triggers are existed
2) Constraints - if any
3) Index fragmentation
4) Page splits / fill factor
Without indexes inserts will be fast because, each time when new row going to insert to the table, SQL Server will do
1) it will check for the room, if no room page splits will happen and record will placed at right place
2) Once the record updated all the index should be update
3) all these extra update work will cause can make insert statement bit slow
Its better to have index maintenance jobs frequently to avoid fragmentation.
If every thing is clear on SQL Server Side, you need look up on DISK IO, N/W Latency between the servers and so on
Thanks,
Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue :)

Transaction span two WLS managed servers (non-clustering)

(Weblogic 6.1 - non-clustering version)
I have two managed servers configured on a single machine on different
ports, and I am not using clustering weblogic. Assuming I have EJB A
deployed on managed server 1, and EJB B deployed on managed server 2.
I want to have EJB A to invoke EJB B. In EJB A, I guess I will
probably create the InitialContext with the URL of managed server 2,
then do the JNDI look up and call EJB B.
My questions are:
- Can weblogic handle transaction that spans two managed servers
(non-clustering setting)?
- Does weblogic use XA to handle transaction between managed servers?
- Do I need to do any JTA code in order to achieve that (instead of
just letting the EJB container to handle the transaction for me)?
Thanks in advance!
B.L.

Hi,
"benson" <[email protected]> wrote in message
news:[email protected]..
(Weblogic 6.1 - non-clustering version)
I have two managed servers configured on a single machine on different
ports, and I am not using clustering weblogic. Assuming I have EJB A
deployed on managed server 1, and EJB B deployed on managed server 2.
I want to have EJB A to invoke EJB B. In EJB A, I guess I will
probably create the InitialContext with the URL of managed server 2,
then do the JNDI look up and call EJB B.
My questions are:
- Can weblogic handle transaction that spans two managed servers
(non-clustering setting)?Yes, it can.
- Does weblogic use XA to handle transaction between managed servers?Yes, it does. Make sure you use TX DataSources. If the servers are connected
to different databases, TX DataSources should be based on connection pools
used XA drivers.
- Do I need to do any JTA code in order to achieve that (instead of
just letting the EJB container to handle the transaction for me)?No, you don't. WebLogic will take care about handling
distributed TXs.
Regards,
Slava Imeshev

DB copy from non-clustered JAVA only to MSCS clustered JAVA only?

Hi!
We have 2 EP7.0 based on SQL server ready for DB copy.
The source EP7.0 is non-clustered
The target EP7.0 is MSCS clustered.
The guide called "System Copy for SAP Systems Based on NW 7.0 SR2 Java"
does not have any coverage on this scenario.
Could you direct me to some related documents?
Thanks a lot!

Thanks!
However I want to give more details.
I have done DB copy between non-clustered systems many times. For example I just
finished 2 recently. The procedure is
1) export CI from the source
2) export SQL server DB from the source
3) restore the DB onto the target
4) import the CI into the target.
Now the challenge is the source is a non-clustered EP, the target is an MSCS clustered
EP. Both are running with the same SID.
My question is :
Do I need to do 1) and 4) in the current scenario? i.e. Do I need to do CI export /import?
If YES, becuase the source is a central system, I have to choose "DB and CI export".
But because the target is a clustered (distributed?) one, the import will match?
Thanks!

Running transactional replication on SQL server 2008R2 but: "The process could not connect to subscriber 'SERVER NAME'"

I've set up Replication (transactional replication) between two remote servers. On the one of server that I configure Distribution & publication .another server is subscription. The subscription is all set & snapshot agent is started .but the actual
replication doesn't take place.
When viewing the Synchronization Status of the subscription, i get an error, saying "The process could not connect to Subscriber ‘Server name'."
Clicking on start, this is the error message I get:
The agent could not be started.
Additional information:
An exception while executing a Transact-SQL statement or batch.
SQL Server Agent Error: Request to run job Server1-EDUSRV-Pubs-Server2-14 (from User Server1\Administrator) refused because the job is already running from a request by User sa.
Change database context to 'EDUSRV'.(Microsoft SQL Server Error:22022)
What can i do?
Please help me.Thanks

The error The process could not connect to Subscriber 'Server name' indicates that the Distribution Agent process account does not have enough permissions to connect to the Subscriber.
If this is a push subscription, verify the Distribution Agent process account is db_owner in the distribution and subscription databases, is a member of the PAL, and has read permissions on the snapshot share.
If this is a pull subscription, verify the Distribution Agent process account is db_owner in the subscription database, is a member of the PAL, and has read permissions on the snapshot share.
The permissions required are covered in
Replication Agent Security Model.
If you have anymore questions, please let me know. I hope this helps.
Brandon Williams (blog |
linkedin)

Transactional Replication: Non-Clustered Indexes not copying.

Similar Messages

Maybe you are looking for