I am doing transaction replication for indexed views. I have other replicating schemabound views that reference the indexed views using the NOEXPAND hint. Even though I call sp_addarticle for the NOEXPANDing views after calling sp_addarticle for the indexed views, I'm getting the error:
Hint 'noexpand' on object '...' is invalid.
because SQL Server is trying to create the NOEXPANDing view at the target server before creating the index on the indexed view.
Is there a way to force SQL Server to finish replicating the indexed view indexes before starting on the NOEXPANDing views?
Have a look on the distributor database and you'll find scripts for pre and post replication. These are straight forward sql scripts so you can modify these and put whatever you like in them.
That means you could modify the pre-repl script to avoid the error and modify the post-repl script to add the noexpanding view after the index has been created.
I think i've found an easier way.
When adding an indexed view to replication using the GUI, will only copy across the schema definition meaning any Stored Procs that try to access these views will error if they contain a NOEXPAND hint.
Now I guess you can mess around with the pre/post scripts but using this article from MSDN: Indexed Views - Replications - NoExpand Hint there seems a simpler option.
You can replicate the indexes by changing the script for sp_addarticle and replace #schema_option from 0x0000000008000001 to 0x0000000008000051. The following example allows both clustered and non-clustered index to be generated at the subscriber.
This pulls across the indexes automatically and has meant less scripting too.
Related
I know materialized view and I'm using it. I have never used indexed views but I will. What are the differences between them ?
SQL Server’s indexed views are always kept up to date. In SQL Server, if a view’s base tables are modified, then the view’s indexes are also kept up to date in the same atomic transaction.
Oracle provides something similar called a materialized view. If Oracle’s materialized views are created without the **REFRESH FAST ON COMMIT** option, then the materialized view is not modified when its base tables are. So that’s one major difference. While SQL Server’s indexed views are always kept current, Oracle’s materialized views can be static.
I am attempting to create an indexed view on SQL Server 2008. I have a master database in which I cannot make any changes to (in terms of adding tables, views, etc.). However, I need to create some different views for various reasons that need to work with live data.
I have created a new database along side my master database so I can create views there. I am able to create views just fine, but I want to index some of the larger views. However, when I try to create a schema bound view cross-database, I receive the following error:
Cannot schema bind view 'dbo.Divisions' because name
'master.dbo.hbs_fsdv' is invalid for schema binding. Names must be in
two-part format and an object cannot reference itself.
Since I am going cross-database with the views, I have to reference the name in three-part format.
My creation statement for the view:
CREATE VIEW dbo.Divisions WITH SCHEMABINDING AS
SELECT master.dbo.hbs_fsdv.seq_ AS DivisionID,
master.dbo.hbs_fsdv.fs_division_desc_ AS Description
FROM master.dbo.hbs_fsdv
How can I create an indexed cross-database view in SQL Server?
Plain and simple. You can't. From the MSDN page:
The view must reference only base tables that are in the same database as the view.
https://msdn.microsoft.com/en-us/library/ms191432.aspx
Although (per the docs) it cannot be done directly with a simple SQL statement, this use case is very common and has a solution.
The architecture would have to involve caching the remote tables into your centralized database, and building the indexed view on top of them.
Some good notes on this can be found here:
What is the best way to cache a table from a (SQL) linked server view?
and
https://thomaslarock.com/2013/05/top-3-performance-killers-for-linked-server-queries/
I've been researching a bit on the use of indexed views and the noexpand hint in SQL Server and needed some clarification. Let's assume for this example you have two situations.
An indexed view is created against a table which already has an index created for the underlying table
An indexed view is created against a table which does not have an index created for the underlying table.
If we omit the noexpand hint, will SQL Server utilize the the view index in either situation? Or is noexpand only applicable when the table has an index and there is a choice to be made?
Secondly, does this behavior vary between editions of SQL Server? Has anything changed in 2012?
Depending what message board, blog, or MSDN documentation you read, it's a little unclear.
I'm using a MS SQL Server db and use plenty of views (for use with an O/R mapper). A little annoyance is that I'd like to
use schema binding
update with scripts (to deploy on servers and put in a source control system)
but run into the issue that whenever I want to e.g. add a column to a table, I have to first drop all views that reference that table, update the table, and then recreate the views, even if the views wouldn't need to be updated otherwise. This makes my update scripts a lot longer and also, looking the diffs in the source control system, it is harder to see what the actual relevant change was.
Is there a better way to handle this?
I need to still be able to use simple and source-controllable sql updates. A code generator like is included in SQL Server Management Studio would be helpful, but I had issues with SQL Server Management Studio in that it tends to create code that does not specify the names for some indices or (default) constraints. But I want to have identical dbs when I run my scripts on different systems, including the names of all contraints etc, so that I don't have to jump through loops when updating those constraints later.
So perhaps a smarter SQL code generator would a solution?
My workflow now is:
type the alter table statement in query editor
check if I get an error statement like "cannot ALTER 'XXX' because it is being referenced by object 'YYY'."
use SQL Server Managment Studio to script me create code for the referenced object
insert a drop statement before the alter statement and create statement after
check if the drop statement creates error and repeat
this annoys me, but perhaps I simply have to live with it if I want to continue using schemabinding and script updates...
You can at least eliminate the "check if I get an error" step by querying a few dynamic managment functions and system views to find your dependencies. This article gives a decent explanation of how to do that. Beyond that, I think you're right, you can't have your cake and eat it too with schema-binding.
Also keep in mind that dropping/creating views will cause you to lose any permissions that were granted on those objects, so those permissions should be included in your scripts as well.
I plan on updating some table names by create a synonym of the old name and renaming the table to what I want it to be. Can replication properly reference a synonym?
Also as a side question, is there an easy way to see if a specific table is actually being replicated? (via a query perhaps)
I don't think so. Replication works by reading the log and there are no log records generated for a synonym. As to your question about finding out which tables are replicated, a query on sysarticles in the table should get you where you want to go. HTH.