Here are something to check with.

Does local select makes difference? if fast, then check network.

Check query execution plan on select, setup index to see the effect. It should unless the...

select @sstring='select FDT_V_FIRECODE,FDT_V_DESC,FDT_V_COUNTY from ZCM_FDT_FIREDISTRICT where FDT_V_FIRECODE like ''%'+@fdt_v_firecode+'%'''

You need index on the table for both speed and data integrity reasons.

Are you in SQL2000 with FULL recovery model?

Performance can change dramaticly once a threshold has been reached.

If restart sql server help, it may relate to log file or memory leaking etc.

Also check log file growing limitation.

That comes to the same issue of none-clustered installation. You may have to clean up registry(on every node) before try it again.

You can use the existing virtual server name or if you do not like it, create another one. Both are valid options.

You may have to rebuild the registry.

 It sounds like entries in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\Parameters

are not correct.

Take the cluster resource offline, drop it and try it again.

BOL search on 'How to create a new failover cluster (Setup)'. It has step-by-step instructions.

net stop mssqlserver

net start mssqlserver

and schedule it at windows level (at command).

Most likely it uses table scan instead of indexes, that explains large tables are most effected.

Do a reindex may help.

DBCC DBReindex or DBCCIndexDefrag

Did you install the instance on existing virtual server or you created a new virtual server, then try to install sql server on the virtual server?

Somehow I feel that it would be much easy for one-one level log tracking, instead of one-many (sa_LogTable logs all changes) for the following reasons.

1. multiple columns primary key.

2. none-key table.

3.varchar length limitation.

Replace

declare @i varchar(100)

set @i = ' 1 456 9'

set @i=replace(@i,' ','')

select @i

disk compression is one place to look at.

Thinking disk partition cluster size may also play a role.