if you can restore close to the failure try this:

DECLARE @filename nvarchar(1000);
SELECT @filename = cast(value as nvarchar(1000))
FROM ::fn_trace_getinfo(default)
WHERE traceid = 1 and property = 2;
SELECT *
FROM ::fn_trace_gettable(@filename, default) AS ftg

if you have backups and happen to have a log backup close to the time of failure you may be able to restore that and query what was running at...

if SQL services were stopped i cannot think of a way

is this the first time it has happened?
do you limit the size of TempDB?
how big is...

the largest database i have worked with was only 2tb
but i have worked mainly in OLTP environment
i would not mix OLTP and OLAP queries on the same database...

how are you currently using the database and how is it performing?
how much I/O do you generate during peak usage?
what is your recovery requirements?

what hardware are you planning to use?
will this be hosted or local?
i assume you wont be using azure or another SaaS offering?

that is a bit above my experience....SQL will happily hold a table of that size....but whether you can actually use it efficiently depends on your application, code etc.

no limit to table size apart from the amount of disk space available
limits exist for partitions per table or index (enterprise version) which is 15000 i believe
limit on...

since checking the stats it seems this wait type has been around for a while...sorry...misinformation!

sure...added as txt file....no graph im afraid

let me know if this is ok...if not i should be able to screenshot but txt may be a little small

wrong choice of words....the locking behavious is obviously correct...you would know above all others!!

whether that is happening here may be in question depending on the exact deadlock information

many thanks gail

when you have a second to confirm your theory by checking the deadlock graph.

i missed the page/table lock above the rowlock bit....that makes much...

just to note....these two queries deadlock frequently and either can be the victim...depends on timing

was assuming it was an index lock maybe but all locks seem to be...

no...i asked one of their support engineers what the wait type was and the reply was: are you seeing any performance issues?

so im guessing they want to investigate...

oops....first query above was for my SPID....without i see about 35 application sessions

slight edit gives this: