You restore the full with no recovery, then the diff with no recovery, then the logs, all with no recovery except the last one.

To start, there's no silver bullet. Most likely what's happening is that your data volumes are growing and either the queries can't use indexes efficiently or the best indexes don't...

Pretty much, yes.

Open transaction would be the reason the locks were held. locks taken by data modifications are held until the transaction completes

No, it's not correct.

he backup will be at most the size of data + log file and will generally be smaller.

Running it in SSMS doesn't mean he didn't use a transaction. Check for open transactions.

Did he start a transaction before running that and not commit it?

Unless you had some auditing in place, I doubt there wouid be any evidence. I've never noticed log entries when setting up replication myself.

You might check the default trace, but...

Pick a good clustered index, create it on the table and leave it there.

I don't think it gets logged anywhere. At best, if there's anything in the SQL error log (which I've never seen) it'll have the SQL login name. So if it's...

Create a clustered index and *leave it*. There are very few good reasons to have a heap table. Just pick a good clustered index, create it on the table and...

No.

Table variables are temp tables with different scoping and a lack of statistics. That's all. They're temp tables. They live in TempDB. They are physical tables and always have been....

DEfinition of the table and all indexes?

Table variables (which are NOT memory-only) don't have statistics. This generally makes them a huge performance problem.

Create a clustered index on that table (and leave it there). There are few good reasons to have a table as a heap, very few. The storage engine is designed...