Don't add an id as a PK, just use MsgDate and MsgTime as the (nonunique) clustering keys. That's how you'll lookup and process this data anyway.

I can't imagine how these tables in their current state are being UPDATEd or SELECTed against, only INSERTed to.

If that's true, or 99.999% true, then I suggest the following, which does involve very brief unavailability, but we should be talking just a few seconds; realistically, I don't think you can do this with "no" downtime.

1) create a new table with columns identical to your existing table, but go ahead and add the clustered index on ( MsgDate, MsgTime ), for example:

CREATE TABLE NetworkWarnings__New (

MsgDate varchar(10)

,MsgTime varchar(8)

,MsgPriority varchar(30)

,MsgHostname varchar(255)

,MsgText varchar(2048)

)

CREATE CLUSTERED INDEX NetworkWarnings__CL ON NetworkWarnings_New ( MsgDate, MsgTime ) WITH ( FILLFACTOR = 100 ) ON [PRIMARY] --chg filegroup name if/as needed

2) Rename the existing table -- this will require an exclusive lock -- and then rename the new table to your existing table name:

BEGIN TRANSACTION

SELECT TOP (0) * FROM NetworkWarnings WITH (TABLOCKX)

EXEC sp_rename 'NetworkWarnings', 'NetworkWarnings__Old'

EXEC sp_rename 'NetworkWarnings__New', 'NetworkWarnings'

COMMIT TRANSACTION

3) Existing code can then continue inserting into the original table name, but it will only be new data, since all the old data has been effectively moved to the other table.

4) You can then work with the old data as needed without any further interference to current activity.

5) After getting the old table rebuilt as you want it, you will have to do another similar thing to merge the table rows that have built up since the rename into the rebuilt "__Old" table.

6) One final transaction can do the final switch of copying the last handful of new rows into the Old and doing the renames again to make the Old the true, master log table again.