“The process encountered operating system error ‘ ɫ’.”

Yeah I don’t know what that character is either, and Google hasn’t heard of that error.  So after proving that replication works with the publisher, distributor and subscriber through a new database with a single table and a single record, I recreated the snapshot, adding an article at the time in case it was a data problem.  Well after adding about 25 of the 35 articles I got the bubble that said C: Drive was running out of space.  I thought, that was weird as the snapshot is going to the L drive, so something else must be happening and I started digging through.

Well it turns out that in the case of compressed snapshots, it first writes the uncompressed snapshot to the temporary location based upon the SQL Server Service account’s user environment variables.  In this case it was the default of “C:\Documents and Settings\[Service Account]\Local Settings\Temp\[GUID]\”.

When you’re not doing a compressed snapshot you can specify any location you want, however in the case of compressed snapshots, you only specify the location of the compressed snapshot, I have not found a way to specify a default location for the uncompressed snapshot. 

So if you’re doing compressed snapshots make sure that the C drive has plenty of space or change the environment variables to point to another drive which does have enough room.

Anyway, as always the best place I have found to look for SQL version information is SQLSecurity.com.  Although Microsoft also keeps one for 2005 here and SQL Server Central also keeps a list here.

SELECT    sder.session_id AS [SPID],    sdes.login_name AS [Login],    sd.name AS [DBName],    sder.start_time AS [Start Time],    sder.status AS [Status],    sder.command AS [Command],    sdet.text AS [SQL Text],    sder.percent_complete AS [Pct Cmplt],    sder.estimated_completion_time AS [Est Cmplt Time],    sder.wait_type AS [Wait],    sder.wait_time AS [Wait Time],    sder.last_wait_type AS [Last Wait],    sder.cpu_time AS [CPU Time],    sder.total_elapsed_time AS [Total Elpsd Time],    sder.reads AS [Reads],    sder.writes AS [Writes],    sder.logical_reads AS [Logical Reads]FROM    sys.dm_exec_Requests sder    CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sdet    JOIN sys.dm_exec_sessions sdes on sder.session_id = sdes.session_id    JOIN sys.databases sd on sder.database_id = sd.database_idWHERE    sder.session_id <> @@SPID;

select
                'Object Name' = so.name,
                'Index Name' = si.name,
                'Type Description' = si.type_desc,
                'FileGroup Name' = sfg.Name,
                'System FileName' = sdf.Name
from
                sys.indexes si
                join sys.objects so on si.object_id = so.object_id
                join sys.schemas ss on so.schema_id = ss.schema_id
                join sys.database_files sdf on sdf.data_space_id = si.data_space_id
                join sys.filegroups sfg on sfg.data_space_id = sdf.data_space_id
where
                so.type = 'U'
                and so.Name not in ('dtproperties')
order by
                3 desc, 4, 1, 2

So I’ve been running a trace on some SQL 2005 servers for awhile now and I’m starting to analyze them.  One of the things I look at is statement top 10 duration.  It was interesting to see all 10 entries to on every day I monitored to be:

TextData – exec sp_readrequest @receive_timeout=600000
ApplicationName – DatabaseMail90 – Id<2224>
Duraction – 609325251

The Id varied and the duration went up and down a little but that seemed interesting to me.  I initially thought I had a Database mail problem and went to investigate.  Nothing seemed out of place.  So I went to BOL and looked up sp_readrequest only to find out it is an undocumented sp.

In fact doing a google search only comes back with 14 entries and only 1 really gives decent information which you can see here.  But basically it said to ignore the entries as it’s not doing any Reads, Writes, or CPUs as it is essentially doing a WAITFOR.  Evidently this is due to the fact that Database Mail utilizes Service Broker to operate.

While I understand and don’t have a problem with things happening behind the scenes that should be ignored, I do think it’s poor that these things we’re supposed to ignore are undocumented anywhere.  In effect, how do we know it’s performing "by design" and should be ignored if we don’t have any information about it?