I don't know any software which scans/detects virus in documents store in tables...

It is always better to protect to your servers using virus protect softeares...

First port is used for regular connections where as second one is used exclusively by DAC. I don't know the command in 2005 where as in 2000 you have to...

http://www.microsoft.com/downloads/details.aspx?FamilyID=b352eb1f-d3ca-44ee-893e-9e07339c1f22&DisplayLang=en

http://www.sql-server-performance.com/vk_sql_best_practices.asp

http://www.sql-server-performance.com/total_sql_analyzer.asp

http://www.winnershtriangle.com/w/Products.SQLServerDocumentationTool.asp

Replication will have more overhead than log shipping but when you do logshipping you kill all the connections in the destination db to restore the log where as replication is...

File being read by your 2005 server might be corrupted, it is nothing to do with sql...

Check application/system log for disk errors...

Try to restore the file where it is located to...

If OBJECT_ID('TABLENAME') IS NOT NULL PRINT 'Table exists..'

Instead of sending the mail in a trigger you can add the column called Flag bit..when you insert or update flag values can be zero ...

Create another procedure and schedule...

There is no problem installing IIS on SQL server 2005. IIS is required to intall REPORTING SERVICES...

IIS 5.0 or later is required for Microsoft SQL Server 2005 Reporting Services (SSRS)...

Some one deleted the data from subscriber directly... In one way transactional replication you have to delete the data at publisher...

In your case some one deleted the data at subscriber...

I used DBCC REBUILD_LOG command 5 times in 3 years and only twice database recovered without any consistency errors..

So becareful about it and withour running DBCC CHECKDB or CHECKTABLE do...

Yes it doable...

Read the topics..."Requirements for Replaying Traces" and "Replaying Traces on a Different Server" from the following article...

http://www.microsoft.com/technet/prodtechnol/sql/2000/books/c10ppcsq.mspx

Non clusterd index is point to clustered index if there is a clustered in on the table becuase of fast retrieval... navigation from level to another done by the key...

For schema change use "ALTER SCHEMA (Transact-SQL) " command...

To move the table between the filegroup you have to recreate the clustered index with the filegroup specified....

I don't think there is anyway to estimante the log file size but you can check the log file size every few minutes and inrease it if there is no...

Run the backup to disk and copy the backup file to CD or USB.