Sql-server – Update Table with Network Client Connection Status, I need help with DB design. SQL 2008 Ex R2

I can't give you an answer to question 1).
But to answer question 2):
What you are requesting is known as the "sliding window scenario".
If you want to eliminate a partition containing data that is no longer needed you have to perform following steps:

• Create a table on the same filegroup as the partition you want to delete (typically, this table is referred to as a staging table).
  This table has to have exact the same structure as the partitioned table, including indexes.
• Switch the partition to the staging table
• You have to remove the reference to the filegroup from the partition function vie MERGE RANGE ...
• Now you can truncate the staging table and drop it. What is left is an empty filegroup you can remove, too.

Some more details on this at http://technet.microsoft.com/en-us/library/aa964122.aspx and the white paper on partitioning, available under http://msdn.microsoft.com/en-us/library/dd578580%28v=sql.100%29.aspx.

The trigger looks ok in principle IF you have an index with IMEI as the first index column on the trackers table and if you don't have lots of records with the same IMEI in the trackers table.

However, unless you have additional indexes on the TraceData table that you didn't show us, any search of course is going to be slow, since it always has to scan all rows in the table. If you need to search for certain column values, like a specific vehicle, you have to add a nonclustered index for that column to speed up the search.

Since you are running enterprise edition you might also consider to partition the table and any indexes based on the ID values or an (additional) date column. I assume that old data gets deleted some time and this will be a very lengthy operation if you don't have this data in a partition. It will also reduce the number of index levels and thus speed up search operations. Read this for example.

Also, you may want to place your data on other filegroups than "PRIMARY". Additional Filegroups (and files) can offer performance benefits, can be set to READONLY to host older data (that then doesn't take up valuable backup resources any more) and enable you to do cool things like online restore with enterprise edition. Check out this cool video from Kimberly L. Tripp.

If you already have an index on trackers.IMEI and insert is still slow, consider using Service Broker in the trigger instead of updating the dependent tables directly. Service Broker takes a message with the necessary content to do these updates/inserts later and then immediately gives control back to the caller, processing the message later in a different thread, taking advantage of your multiple cores (which a simple insert cannot do) and thus speeding up the trigger.