Typically EXISTS / NOT EXISTS is most efficient when it's a viable option.

You'll want to have a (nonclus) index on B ( AppId, NotificationDate ).  If the table already has...

Agree with Phil, that's a critical q.

Also, efficiency will depend on the indexes on the tables.  You'll need to be able to review indexes.

(dup)

Try these and see if they help.  Be sure to review the query plan to verify:

INDEX ON mq: ( TABLE_NAME, ROWID_MQ_DATA_CHANGE )

UPDATE mq
SET mq.sent_state_id = 6,
UPDATED_BY =...

It would be simpler and more efficient to just calc the 3rd Friday of the month and then see if there are any rows for that date, i.e., you don't...

I don't see why you'd need more then 150GB of RAM for a 31GB table.  If that's "the big table" in the db, presumably the entire is only 50 or...

Agreed.  You really want to have all the dbs having the same owner.

We would need DDL for the tables and some cardinality info (how many rows for each condition).

But, overall, IF that is a consistent query pattern, you should cluster the table...

I prefer the 2nd approach, but for the 1st approach:

The processed_flag should be a bit, 0/1, rather than a full char (y/n).  If you already have a bit column(s) in...

Need sample data that is directly usable, that is, CREATE TABLE and INSERT statement(s), not just a splat on the screen.

D'OH, sorry, that should be:

CAST(GETDATE() AS date)

You've already got restrictions based on @LOOK_BACK_PERIOD in the WHEREs, it would just be more efficient to pre-filter rather than waiting until some processing has been done on all the...

Did you add the WHERE condition for the TXN_DATE?  If you have a long history in the table, that would help the most.

Then try an index on (txn_date, company) include...

Need the DDL for the table to sure of more specific recommendations for best speed, but, assuming you will keep a long history in this table:

(1) Either: (A)...

Need the DDL for the table to sure of more specific recommendations for best speed, but, assuming you will keep a long history in this table:

(1) Either:

(A) cluster the table...