@jcolebrand I've got two cases for it and might give it a shot this weekend. HTPC/LabServer at home and now my laptop, as I'm doing more and more TFS/VS/Automation work and need the Hyper-V
I'm the process of planning the live migration of a 2TB database to partitioned tables. The system is broadly speaking a document store, the majority of the space being allocated to LOBs of between 50kb and 500kb, with a small percentage in the 500kb to 1MB range. Part of the migration will invol...
@gbn Isn't an online rebuild of 500m rows going to be more chaotic than attempting an update?
My money would be on it being an incrementing range, which the trace flag i mentioned should tackle.
Correction, 330m rows
I get the feeling the chap isn't going to listen to anything other than his original Q anyway, judging by his intitial response to John Sansom and the tone in his comments
Is it possible to force FULLSCAN when statistics are updated automatically by SQL Server 2008 R2?
If not, is a planned UPDATE STATISTICS WITH FULLSCAN the best way to keep statistics up-to-date?
note: The need for the FULLSCAN comes by proved suboptimal plan generation when using non-FULLSCAN ...
His original SO question mentioned that seeks are used when the plan is good though "I don't really see what that has to do with the actual question... anyway, consider that the suboptimal plan used two clustered-index scans whereas in the optimal one they are not present (replaced by seeks on the same indexes)."
@MarkStoreySmith I noticed you updated your answer to my question about one vs. many databases. It still says "Scaling out would be the correct term but yes" which, as I noted in the comments, is incorrect.
@JackDouglas re: this answer do you have a large data set to test against?
`with w as (select x, cast(collect(y) as table_integer) as ys from t group by x) select w1.x as subset_x, w2.x as superset_x from w w1 join w w2 on (w1.x<>w2.x and w1.ys submultiset of w2.ys);`
@Nick was just fixing a typo, let me refresh my memory on the comments
@Nick ok, think we're talking at cross purposes on that bit. I think my point was that when the term "scaling up" is used it refers to adding more cpu/memory to a single server, "scaling out" being multiple machines. So your "Assuming each database is on separate hardware, scaling up yields more performance benefits." is sort of mixing the terms if you see what I mean
Could probably tidy the answer and comments up a bit if you like?
I'll move some of the comments in then we can ask a mod to delete the comments
you've already scaled out by having the databases on separate machines, so then scaling each of those up yields more benefits than scaling one machine with one database up
which is a mix of the two
@JackDouglas What constraints/indexes do you have on the table, btw?
@MarkStoreySmith I clarified my scaling up statement in my question. We can delete all the comments we have, minus the one about SAN caching (which I think is still relevant)
@JackDouglas would you mind doing a chit chat cleanup on dba.stackexchange.com/questions/4547/… for @Nick and I. Just leave Nicks comment regarding SAN cache in place please.
@Nick thought you might like to know your answer wins by a factor of 200 or so against the collect/multiset :) (and a factor of 2ish over my other answer)
this answer on the other hand, fit without requiring a scroll bar (I actually edited the code so it would fit the 600px limit) and delivers powerfully right there
@MarkStoreySmith heh, I still haven;t gotten around to that. my company put that off for a future sprint, which is why I haven't accepted an answer yet
@MarkStoreySmith Im leaning towards that at the moment, plus an INSTEAD OF trigger to capture the old balance in the same row as txn amount and new balance
The additional write to an indexed view is very different to an additional write to a balances table for instance.
Holding the current balance on the account record, combined with recording transactions with an opening balance (as per Andrews answer) sounds like the best route to me
But its one of those I'm inclined to hack some code together for :)
What information do you think needs to be in the header block of our FAQ?
Check out some of the FAQs of our sister sites:
http://english.stackexchange.com/faq
http://gaming.stackexchange.com/faq
http://photo.stackexchange.com/faq
and especially http://programmers.stackexchange.com/faq
I'm s...