BLOB_EATER (10/19/2016)

---

Brandie Tarvin (10/19/2016)

---

ThomasRushton (10/19/2016)

---

rodjkidd (10/19/2016)

---

are you sure...

Jeff Moden (10/18/2016)

---

Using compress backups and having a really good team that put together some remarkable hardware, I'm backing up 2.3 TeraBytes to Network Attached Storage (NAS) in 1 hour...

Phil Parkin (10/18/2016)

---

ChrisM@Work (10/18/2016)

---

Here's the ROW_NUMBER version. I think the index...

You're welcome, thanks for the feedback. If you get...

Here's the ROW_NUMBER version. I think the index I posted earlier...

Sure no probs - but do try that index 😉

I can't see your indexes, can you confirm that this is one of them? If not, create it and test with both queries.

(entity, LogTxt, entityRowID) INCLUDE (LogDate, userName)

There's...

BLOB_EATER (10/18/2016)

---

Grant Fritchey (10/18/2016)

---

Wow, just read the comments on Reddit about a recent blog post... ouch.

Evidently stating the obvious when others are stating the opposite is not allowed amongst those...

seismicbeat (10/17/2016)

---

Hello,

I'm a SQL Server novice. I've been polishing up on my T-SQL skills while working for the last few months and I was tasked to come up with a...

Rechana Rajan (10/17/2016)

---

ChrisM@Work (10/17/2016)

---

There are at least two issues here which will unnecessarily prolong an INSERT transaction using this process.

Firstly, as Jeff pointed out, the SELECT. Use the OUTPUT...

No problem Rechana. Whilst Googling for [Forced Index = True] I came across this wonderfully succinct article by Grant Fritchey[/url]. A great starting point for reading and interpreting execution plans....

There are at least two issues here which will unnecessarily prolong an INSERT transaction using this process.

Firstly, as Jeff pointed out, the SELECT. Use the OUTPUT clause instead, like...

Brandie Tarvin (10/13/2016)

---

GilaMonster (10/13/2016)

---

Grant Fritchey (10/13/2016)

---

Sean Lange (10/13/2016)

---

WOW...http://www.sql-datatools.com/2016/05/sql-queries-tuning-and-optimization.html

This is supposed to be a list of things to do to optimize queries. While some of these are valid most of them...

-- Most of the cost of the query is reading the

-- portfolio table - with the aggregate performed AFTER this expensive bunch of seeks.

-- This version of the query might...

-- Your query matches portfolio.clientID to deadline.clientID

-- where does #Temp1.clientID fit into this?

-- It might be possible to do something like this

UPDATE a

SET Ret = x.Ret

FROM #Temp1 a

CROSS...