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.
Related
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.
Is it possible / practical to add a constraint (i.e., Primary Key or Index) to a view?
I am using SQL Server 2000 and the view queries multiple tables across 2 databases.
I know how to add a constraint to the tables that host/build the view. Those indexes are there. They just don't seem to carry over to the view.
Thought? Ideas? Suggestions?
Thank you.
If your views don't violate any of the long list of requirements, you can create a clustered index on your view in SQL Server 2000, and thus speed up queries quite a bit.
See:
SQL Team: Indexed Views in SQL Server 2000
MSDN: Improving Performance with SQL Server 2000 Indexed Views
Anything else isn't supported, as far as I know - if you want a constraint, you need to constrain the underlying base tables.
If you have a concrete problem with a view, maybe you need to explain in more detail. What do your base tables look like? What kind of data (and how much) is in there? What does your view definition look like? What are the queries you run against that view, and how does it behave - is it "just slow" or do you get wrong results, or what's the issue?
Does anyone have experience of when SQL Server 2008 R2 is able to automatically match indexed view (also known as materialized views) that contain joins to a query?
For example the view
select dbo.Orders.Date, dbo.OrderDetails.ProductID
from dbo.OrderDetails
join dbo.Orders on dbo.OrderDetails.OrderID = dbo.Orders.ID
Cannot automatically be matched to the same exact query. When I select directly from this view with (noexpand) I actually get a much faster query plan that does a scan on the clustered index of the indexed view. Can I get SQL Server to do this matching automatically? I have quite a few queries and views and I do not want to reference the indexed view manually each time because I am using an OR mapper.
I am on enterprise edition of SQL Server 2008 R2.
Edit: I found the solution. SQL Server 2008 R2 does not match indexed views with more than 2 joins automatically. Probably it would slow down the optimization process too much.
Edit 2: Reviewing this 2 years after the question was created by me, I don't think my conclusion was correct. Materialized view matching is a very fragile process with no clear rules that I could find over the years.
Certainly, the following play a role:
Number of joins
Presence of a predicate
Join order, both in the view and in the query
I'm a little fuzzy on exactly what your question is; but I think this will give you what you want:
http://msdn.microsoft.com/en-us/library/ms181151.aspx
There are a lot of strange, arbitrary-seeming conditions that limit when SQL Server will use a view index in a query. This page documents them for SQL Server 2008.
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.
The dynamic management views of SQL Server 2005 can give usage information about table indexes. Is there a similar method for getting usage information about column statistics? In specific, I'm curious if some of the older column statistics I've created are still being used. If not, I'd like to delete them.
no there isn't. there are however sys.stats_columns and sys.stats catalog views