« first day (3811 days earlier)      last day (1057 days later) » 

12:22 AM
@PaulWhite :)
I hear MySQL has been invading its territory for years
 
1:10 AM
Good morning Heap.
Does anyone have real-world experience with SQL Server Change Tracking? War stories, gottchas, successes?
 
 
1 hour later…
2:26 AM
^Would be interested in hearing from those with experience on this too. I've read about it a few times over but have no real world experience currently, but likely will be using one of these type of features in the near future.
 
2:37 AM
I was going to use change tracking and had proof of concept and everything all built, but maintainers of source system did not want to turn it on in their product's database, so we ended up using some triggers with service broker to decouple the processing as they were thought to be less invasive.
Looking back, probably was the right decision, given the number of times they restore and reset that database during their testing and development. Troubleshooting making sure we handle what they do in their build and test cycles that do that customers never do seems to take a while.
 
3:19 AM
We had CDC enabled. Stuff happened and it took the blame. Now we need a plan B. This is to feed end-of-day values into a warehouse. CT seems to fit the use-case. Never used it in real life so I thought I'd ask around.
 
i avoid it in favor of change data capture as much as possible
 
Actual triggers would work well. After recent events The Business is wary and we don't want to .. um .. trigger <tee hee hee> the same reaction.
 
too much overhead in high volume transactions
 
Thanks Erik. CDC was working beautifully. Right up until it hit our production server's TLog just before go-live. sad face dot gif.
 
Isn't there a force seek perf fix for CT in CU11?
 
3:25 AM
In prod there are some large overnight batch activities which touch a lot of rows. Combined with hardware that could have been better configured, it was all just too much.
 
I've used both over time and hated them each equally. Too long ago to remember details or possibly even still be relevant
Like most add-on tech I suppose
 
3:44 AM
Replication is still the worst
 
Do you have an article on that?
 
4:01 AM
@MichaelGreen You may already have seen brentozar.com/archive/2014/06/…
 
 
2 hours later…
6:02 AM
@PaulWhite funny you should mention that. We were using tx replication to copy changes from on-prem to an Azure Managed Instance. The MI had CDC enabled, and the DWH pulled from the MI's CDC tables.
What could possibly go wrong.
 
@ypercubeᵀᴹ That was some gruesome tennis. Sakkari (GRE) just lost here nerves and Krejčíková (CZE) just kept here calm. In the end the person with the least amount of errors won.
@PaulWhite ding ding ding Round One!
Morning
 
6:47 AM
Morning
 
 
2 hours later…
8:17 AM
@JohnK.N. yeah, that 4th match point where the umpire said it was in was brutal for Krejčíková but she still kept her nerve.
I'm waiting for today's match, between Novak and the other annoying guy
 
 
2 hours later…
10:49 AM
> The statement on the trust's website advised parents: "It would be very wise to let your bank know that your bank details may have been taken."
> A trust spokeswoman described the hackers as "sophisticated".
 
They always say that
 
11:16 AM
Script kiddies
I checked. My password wasn't included.
But it's nice to know everybody-else's passwords.
 
11:30 AM
@ISupportTheBoycott I wish people would remember that you can use a CASE statement in ORDER BY. Makes things like that a bit easier
 
12:09 PM
@J.D. I can see how that index would benefit the other query, but a full clustered index scan would result for the Column1 one. Yes it may or may not be better. I was mainly wondering what your reasoning was for having both columns as the clustered index key. I wanted to see that made clear in the answer.
> Why not try creating your clustered index on (datetime, Column1)
 
@PaulWhite yah I thought he only used MSSQL, on principle 🤣
@JohnK.N. 2FA 2FA 2FA!
 
@HannahVernon I'm pretty sure it is his secret love
 
12:33 PM
@PaulWhite Sorry I guess where I'm confused is what you're looking for me to elaborate on? Should I add some details on the fact that switching from a key lookups operation to a clustered index scan can be more performant because the query doesn't have seek / scan one index and then perform a second scan on the clustered index, rather the clustered index itself will now provide everything his queries are looking for?
 
Mostly were and when possible.
Google Authenticator or SAASPASS.
 
As far as clustering on both columns, I don't want to misspeak on the why, but doesn't it make sense to if either one is a predicate in his queries. Even if the equality query on Column1 would invoke a clustered index scan? (Also I thought I've even seen clustered index seek operations applicable in that situation before as well, but I don't know why or how that would be possible, so definitely don't want to misspeak.)
 
> heh, how did you place the bet?
To be honest, it was really to make the game interesting! At the time, only a drunken Greek off his/her head on Retsina (which I've never tasted BTW - bucket list...) would have voted for Greece against Portugal (prob. remains true to this day),
but Greece did have flashes of brilliance. Anyway, was out locally, met this chap and he was mouthing off (as usual) - we were nodding acquaintances - his mother played bridge with mine, so I said "Fine, we'll put a Euro on it" - partly to shut him up (Portugal couldn't lose...) and partly to give me an interest in the game...
Come end of game, I say, "Where's my Euro?" (I believe in collecting on my bets and paying out if I lose... - even if the amount is trivial - it's the respect for the other person and the sport...) and he says "I'll have to get it..." - Get what? A fu**7#-ing armoured car to escort your poxy Euro? Anyway, done't care - just won't be making a bet with him again....
 
ah, I see. pub bet ;)
 
The best kind! But I still expect them to be honoured!
 
12:48 PM
I had actually bet 10 euros on the first round, Greece and Spain to win against Portugal/Russia. I think I got about 90
 
Good man - I should have put my Euro on before the championship started - would have made 80!
Greece were dark horses though!
 
I remember the weird surprise on everyone's face on the betting shop when I collected the next day. Apparently no one else had bet on Greece to win the first game.
that was in Greece by the way!
 
I'm not surprised - see my remarks about Retsina! You were collecting in Greece? I'd say that many Greeks (betting with head, not heart) were putting money on Portugal - if you could find somebody to take the bet!
 
oh hey all
 
@J.D. Well you say Why not try creating your clustered index on (datetime, Column1). It is clear how that would benefit the predicate on 'datetime' (with a seek). That index would not benefit a predicate on Column1 alone at all. The result would be a full table scan, so why include it in the clustered index? Seems to me the outcomes would be the same. No it isn't possible in SQL Server to seek starting with the second key column. Some other products (Oracle?) have 'skip scan'.
 
12:51 PM
@Vérace betting shop. of course they accept any bet
 
Just thought I'd stop in to share something that made me laugh in a procedure we found today.

The code was something like

CREATE PROC dropthethings
@table nvarchar
AS

SET @SQL = 'DROP TABLE ' + @table
EXEC(@SQL)
 
good lord
 
I was impressed.
 
@J.D. If you don't have any clarification to add, and it is just a guess-based suggestion, that's fine. I thought you would have some reasoning is all.
 
I don't think I've found an SP where intended use of the SP is just about as destructive as the SQL injections it's also vulnerable to :D
 
12:57 PM
> betting shop. of course they accept any bet
Yes, but what disappointed me was the fact that my interlocutor didn't respect the bet... A betting shop has no choice - do you have horse racing in Greece? I preface my comment by saying that the only thing about horses of interest to me are the bits that are good to eat!
"Iinterlocutor"was the best word I could find without resorting to expletives!
 
I've never heard that word before.
TIL
 
1:11 PM
@George.Palacios - search for perpendicular
 
1:54 PM
Auto-correct is awful today.
 
2:07 PM
@Vérace we do but not many people care about them. Only the gambling addicts ;)
"αλογάκηδες" is a common term/slur for those addicted to horse-race betting
 
@George.Palacios so much better than having an inadvertent SQL Injection vulnerability lol
 
2:33 PM
@ypercubeᵀᴹ I wonder if it's getting slower as it ages, like the rest of us.
2
 
truth
 
@Vérace Seen it! What a great word
@HannahVernon Exactly! :D
 
@Philᵀᴹ It adds more characters and means I lose at SQL Golf.
I wonder if I can get a Gold Badge in Oracle by answering with PostgreSQL solutions...
 
3:16 PM
@ypercubeᵀᴹ - unfortunately, we've lots of them in Ireland - αλογάκηδες = al-oh-gak-eh-des? When you have the world's largest bloodstock industry, there are casualities...
 
@Vérace γ is not g, but close enough.
 
@PaulWhite Sorry busy work day again, just seeing your reply now. Wouldn't it still be a clustered index scan not a table scan?...in any case I guess it would still be a clustered index scan even if the index was just (datetime) (for the query with an equality comparison on Column1). But yea I guess long story short, it just feels correct to cluster on the fields that are his predicates, at least as something to test.
But perhaps, for this kind of case, it would never make a difference one way or the other, from a performance perspective. You have me interested, so if I get some time this weekend, I'll do some testing.
 
Hard or soft "g"? Went out with a Greek girl in Paris years ago - but apart from "daksi" - I've forgotten much! :-)
 
what is hard g and what is soft g?
you mean the diff in pronunciation between go and gem?
 
@George.Palacios In regard to laughable code, the number of times I've seen in production code: if (1 = 0) begin return 1 end is sadly not 0, and even sadder more than once...
 
3:30 PM
@ypercubeᵀᴹ - yes, a hard "g" is "go" and a soft "g" is "gem"!
 
γ is neither
it's more like a strong wh in whiskey, what or w in woo
 
Oh - I thought that gamma corresponded to g - although languages are all different - love languages - Irish has all sorts of pronunciations for "g"... plus it's often silent...
 
it is usually transliterated to g, yes, so I can understand why you thought that
 
Think of French "je" followed by a swishing sound...
It can also be hard - "go" - pron. "guh" - "slowly", "go mall" - "guh mowl"...
The "go" in Irish doesn't mean "go" in English - it's not a cognate!
 
4:01 PM
When you say Irish you mean the Irish Gaelic?
I thought we were talking about English as spoken in Ireland
 
4:46 PM
@J.D. a clustered index scan is a table scan.
 
5:20 PM
you can see that for yourself in this tiny example, in the statistics I/O output, where both SELECT statements result in a clustered index scan, and result in the same number of pages read from the database:
DROP TABLE IF EXISTS dbo.t;
CREATE TABLE dbo.t
(
    id int NOT NULL
        IDENTITY(1,1)
    , someData varchar(8000)
    , INDEX tcx CLUSTERED (id)
);
GO

;WITH src AS
(
    SELECT *
    FROM (VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9))v(n)
)
INSERT INTO dbo.t (someData)
SELECT CONVERT(varchar(8000), CRYPT_GEN_RANDOM(8000), 0)
FROM src s1
    CROSS JOIN src s2
    CROSS JOIN src s3;
GO

SET STATISTICS IO ON;
SELECT t.id --read only the ID column, which is the clustering key
FROM dbo.t t;
You may notice if you do that same exercize on a heap (i.e. no clustered index), it reads only 1000 pages instead of the 1005 pages required to read a clustered index. The extra 5 pages result from how the clustered index is organized. Heaps contain only rows, no index structure.
 
5:34 PM
I think J.D. is just nit-picking about operator names.
When Paul said "The result would be a full table scan" I'm fairly certain he just meant that the base table would be scanned (there wouldn't be any seeking).
He wasn't referring to the "Table Scan" operator.
 
6:34 PM
@JoshDarnell I was responding to this: Wouldn't it still be a clustered index scan not a table scan?
perhaps I'm just too nitpicky lol
 
6:50 PM
I was referring to the different operators and ensuring I'm not missing something, because my understanding is there's a difference in BigO search time between an actual table scan operation vs a clustered index scan (that is over a B-Tree). Perhaps I'm mistaken?...or after your comment @JoshDarnell, it seems like I've just misunderstood Paul's comment. Definitely not one to nitpick, just usually need explicicity to understand a lot of times.
 
7:09 PM
@J.D. there is no difference. In both cases you read the whole table
 
 
3 hours later…
10:03 PM
@JoshDarnell Yes that's exactly what I meant thanks cc: @J.D.
@J.D. Well certainly there are some differences due to the way the table is organised in each case but the logical operation is still a full scan of the table.
For a clustered b-tree table, the engine can start at the first logical leaf page and scan forward at the leaf following next page pointers (or do the same in the reverse direction); or it can be an allocation-order scan driven by the IAM pages in suitable circumstances. A heap can only be scanned from the IAM pages of course.
Having unnecessary keys in the clustered index decreases the index fan-out and bloats non-clustered indexes.
There's no big O difference. Some people have a misconception that accessing a b-tree structure involves a seek for every page. That's not true for the range scan component, where the server follows previous- or next-page pointers at the leaf, as mentioned above
 
10:34 PM
@PaulWhite @ypercubeᵀᴹ Thanks for the clarification, that's actually really interesting and important to know, and I did not know that. I'm a big guy on conceptualization, and I never knew how to conceptualize the difference between how a clustered index seek and a clustered index scan worked, but now I can visualize it. Thank you!
 
@J.D. The other important thing to realise is that most index seeks have a range scan component. The only exception being an equality seek on all keys of a unique b-tree.
 
Sorry, trying to conceptualizing that.^ What would be two examples of predicates that would result in one over the other?
 
👍 thanks!
 

« first day (3811 days earlier)      last day (1057 days later) »