Never had one myself - my first phone was a Sony and my last 3/4 have been Samsung - with maybe a Nokia or 2 in between. I'm not a huge "fan" of phones - I put up with them because they're useful. <rant>The one thing that really bugs the shit out me these days is that everybody wants you to have a fucking app - what was the problem with accessing stuff using the shagging browser.
Recenly my bank has basically forced me to download it - web access impossible without the damn thing!</rant>
Hmm, I have a larger table (2 mil rows, 8 cols, 600 GB fragmented). I'm removing a surrogate PK and replacing with combined index over 4 columns. But then I need to update in batches without creating a temporary index
I've tried offset - fetch in a loop, but it reads the offset rows, so every iteration has more reads
then I'll just update the same rows all over again. If I add condition to check whether it's updated or not, it will scan the table without the temporary index
Update with a WHERE clause. Say first you update only rows with col_a <=3. The second batch has WHERE col_a > 3 AND <= 6. The 3rd WHERE col_a > 6 AND <= 9. etc.
@PaulWhite something like: "use the method of that question to get 1000 rows with an index seek, update them, get the maximum (4-column) values of the rows updated. use that in the next iteration" ?
@Zikato I don't like that option much, for reasons Michael explains well in his post. What are you looking to avoid by creating an indexed view 'online'? As I recall, Sch-M is no longer taken on the base table during the build. Lack of an offline window just in case? Too much pressure on the server when the view build is in progress? Don't you hate that IsMigrated column?
I'm worried about blocking, because the indexed view references a load-bearing table. I don't like the IsMigrated column, but ends justify the means. The index creation took 16 minutes on the Test environment which in case of blocking would be an outage
The documentation for How Online Index Operations Work says:
SCH-M (Schema Modification) if any source structure (index or table) is dropped.*
* The index operation waits for any uncommitted update transactions to complete before acquiring the S lock or SCH-M lock on the table.
That is specific...
@Zikato I see you're too busy to read the whole answer, let me quote the relevant section for you
> Some time ago, the Sch-M restriction was applied when creating an indexed view. That was pointed out to be unnecessary (Connect link no longer available) because no structure was being dropped, only created, so the behaviour was changed (to only take Sch-S and Tab-S).
For the first time in my life, I have some sympathy for Forrest
@PaulWhite I still think we should edit the original, there is no way you are going to get another 300 votes
@ypercubeᵀᴹ dolp and plod are also if you mirror vertically. I have no idea the significance of that though...
@PaulWhite Logically you'd think the optimizer wouldn't even be able to see the indexed view, because the system objects for it haven't been committed yet.
I'm also wondering how will the indexed view affect the readable secondaries. They shouldn't be blocked, because the index is created by the redo thread only after it's finished right?
@Zikato I don't think there's a trace flag to implicitly add EXPAND VIEWS to all queries on a session, if that's what you're asking. There might be other ways to work around this, but it'll take me a while to check.
@Charlieface Yeah, nah we've been over that.
@Charlieface Well, the view exists alright. It might be indexed, but you'd need to check the metadata to determine that. I guess that's where the blocking occurs, but I haven't checked yet.
The most egregious thing I ever saw re indexed views, was a case where I'd created a view something like CREATE VIEW v AS SELECT a / b FROM table WHERE b > 0 and then after I indexed it, when inserting I got weird "divide by zero" errors, even though I'd filtered the zeroes out. Ended up having to put it in a CASE to prevent that happening, but debugging it was annoying as it only happened when inserting to the base table, not when I created the index.
i've had the same thing happen with filtered indexes and computed columns. the computed column one was really funny, because it only happened when i created an index on it.
@Zikato I confirmed the blocking happens when the query processor goes to load dependent views, anticipating that view matching might be tried later. When EXPAND VIEWS is hinted, that step is skipped, so no blocking.
There's no neat way to prevent automatic indexed view matching without that hint on Enterprise Edition, at least without a number of hairy side-effects.
Using the StackOverflow2010 database, I can create an index on the users table as follows:
CREATE INDEX IX_DisplayName ON dbo.Users
(
DisplayName,
UpVotes
)
And then run an inequality search on the key of the index:
SELECT DisplayName,
UpVotes
FROM Users
WHERE DisplayName <>...
The constant scans are a way for SQL Server to create a bucket into which it's going to place something later in the execution plan. I've posted a more thorough explanation of it here. To understand what the constant scan is for, you have to look further into the plan. In this case, it's the Comp...
> ADDENDUM: That last sentence is off. There were two seeks. I misread the plan. The rest of the concepts are the same and the goal, minimal passes, is the same.
@PaulWhite IMO you shouldn't edit someone else's answer to drop in links to your own blog, even (or especially) if you are the mod. Self-promotion and all that. Just put in a comment, I would probably have added it anyway.
Don't be so tedious. It either improves your answer or it doesn't. You already had two links to my work in there. I left a lighthearted edit comment. Do try to develop a sense of humour, even if only a basic one. Jesus
3
Hi @charlieface, I think given Erik's comments above along with your answer, simple parameterization is the answer - something for me to read up on — SEarle19863 hours ago