Sql-server – Empty Table: Insert into Table WITH (TABLOCK)

The log can be forced to grow if you have an old transaction that has not been committed or rolled back, regardless of the size (it could affect a single row). For the database in question, assuming you haven't resolved the problem yet, do this:

DBCC OPENTRAN();

This should show you the oldest active transaction (and there is a good chance this is the one that is preventing the log from wrapping). You can see the last thing they did (but not necessarily the thing that is causing the problem) by (documentation):

DBCC INPUTBUFFER(<spid>);

And if they have a query that is currently running:

SELECT * 
  FROM sys.dm_exec_requests 
  WHERE session_id = <spid>;

You can also see from sys.databases what the log holdup is (it could be something else entirely):

SELECT log_reuse_wait_desc 
  FROM sys.databases 
  WHERE name = N'<database name>';

There can also be reasons why an 80 MB transaction might require more than 200 MB of log space - see Remus' answer here:

• Why does this 120 GB insert grow the log by over 780 GB?

And I recommend you read this page in its entirety (perhaps you are not using the right recovery model, and perhaps you should consider allowing the log more space to grow when it needs to, rather than shutting down all activity until you resolve the situation manually):

• Why Does the Transaction Log Keep Growing or Run Out of Space?

Related:

• Identify cause of unusual transaction log growth
• Contents of transaction log file in more detail
• SQL Server transaction log
• Finding exact statement causing error 3930
• SIMPLE or FULL recovery model for databases?
• SQL Server log file continues to grow?
• Changing a column's data type fills the transaction log
• Log sizes unexpectedly large: log_reuse_wait_desc == "log_backup"

I know that reindexing the PK will lock the table, so I was wondering what best practice for this operation is?

Well having some DB file size/growth and free disk space monitoring would be good so this situation never happens. As you are in this situation I think the plan you have outlined is your only choice until you get more disk space and you really need more disk space.

This script suits our needs for now, but what is considered best practice usually for a table of this size assuming we had infinite available space?

Regular index maintenance would be nice. Try looking at Ola Hallengren's maintenance scripts here to solve that. These scripts provide an almost fully automated methodology for maintenance of your SQL Server databases.