Only do ONLINE rebuild if you really need it.  It has additional overhead and is often not quite as efficient as packing data rows.

Data (page) compression is a great tool...

I suggest not working with partial days.  Therefore, I suggest changing the first query to:

SELECT * FROM dbo.SQL_SOURCE WHERE Mod_Date >= CAST(CAST(Getdate() AS date) AS datetime) -5

I think there should be an explicit "NO REPLACE" option, but MS doesn't have it.

Instead, you can check for the db exiting before you issue the RESTORE DATABASE command:

IF EXIST(SELECT...

SELECT
UserGroup.[Name]As GroupName,
UserGroup.[Description]As GroupDescription,
Domain
FROM [dbo].[UserGroup]
CROSS APPLY (
SELECT NULLIF(CHARINDEX('(', Name), 0) AS start_of_substring, 
    ISNULL(NULLIF(CHARINDEX(')', Name), 0), LEN(Name) + 1) AS end_of_substring
) AS ca1
CROSS APPLY (
SELECT...

DROP TABLE IF EXISTS #data;
CREATE TABLE #data ( string varchar(8000) NULL );
INSERT INTO #data VALUES( 'Domain Administrators (abc.domain.com) Group Members'), 
    ('Engineering Supervisors (xyz.domain.com)...

Do you mean "sysadmin" (vs. "dbadmin").  SQL is very selective about who can see jobs.  If you didn't create the job and aren't sysadmin, you don't typically see the job. ...

SELECT ColumnA

FROM dbo.your_table

GROUP BY ColumnA

HAVING COUNT(DISTINCT ColumnB) = (SELECT COUNT(DISTINCT ColumnB) FROM dbo.your_table)

ORDER BY ColumnA

My main advice would also be not to modify the table structure unless you really need to (I deliberately put the code in comments that (if you wanted to) changed...

It's nice that there's already an index on dDateIn. I would suggest something like this:

--Setup

(A1) Create a new table, with a usable clustered index. Add data compression to the table...

If the table is just a heap (you said there's no PK, but that doesn't necessarily mean there's no clustered index), as you know, you'll have to rewrite the whole...

I think if you do the UPDATE and lookup all in one go, you won't have dups nor deadlocks:

...

UPDATE dbo.Reference_Numbers
SET @NextReferenceNo = NexNextReferenceNo = NextReferenceNo + 1...

• This reply was modified 1 years, 5 months ago by ScottPletcher.

No.  If they're sleeping, and don't have any active tasks, they are not using up CPU.  They are taking a small amount of memory.

I've generally found MERGE to be less efficient than UPSERT.  Others maybe not.

You could generate the necessary WHERE clauses and CASE clauses to conditionally UPDATE 200 columns.

Because * SELECTs all columns, which would include hMy.  Try this instead:

SELECT hMy, *
FROM dbo.WF_HEADER
WHERE 1=1
ORDER BY 1 --<<--

For one thing, don't force only LOOP joins, YIKES!

To tell you anything else, would need much more details on the tables and parameters.