ETL File Management and DTS Import Tips
I have been working with lots of ETL files lately and thought I would pass on some tips I have found in the documentation (ETL Files are still around in OCS 2007 Speech Server so this is still applicable):
Compress .etl files to the Zip Archive file format. By their nature, .etl files contain a lot of repetitive content, which makes file compression very effective. Compressing .etl files to the ZIP format will both cut disk space usage and reduce the network bandwidth needed when copying files to other computers as described in the following bullets.
Before you FTP those ETL files from the customers site zip them up! It will save you time.
Configure Microsoft Speech Server (MSS) to write .etl files out to a local drive on the MSS computer. It is preferred that this drive be separate from both MSS and the operating system. There are two issues here. First, if the operating system drive gets full MSS won't have enough space, which might actually cause calls to fail. Second, logging to a local drive is more efficient. Runtime performance of Enterprise Instrumentation Framework (EIF), and therefore MSS, will suffer if the server has to write all the log file events to .etl files across a network.
These ETL files get very large. Set aside a large drive just for the ETL files and make sure it has a fast write speed.
Importing .etl files to the SQL database directly from the MSS computer may impact MSS performance. To avoid this, before importing .etl files, copy them to a computer other than the MSS computer. To minimize performance impact, the copy operation should be performed off-hours; and by a low priority scheduled task. In order to give the MSS computer control over the task priority, the task must run on the MSS computer. In other words, the MSS computer should push the files onto the destination computer using a low priority scheduled task.
Most customers I have seen do this. I like the thought of having the MSS computer controlling the transferring of the files so that it does not affect performance. Try to transfer them to the SQL Server computer that will be performing the DTS transfer. When the DTS processes is running it is importing the call data from files that are local and not over a network.
Users should choose filters with the smallest number of events possible to meet their needs. If users import audio and all events, the import can take an extremely long time.
You don't always need all the events do you? Try filtering just these 4 events: QASummaryEvent, CallStartedEvent, CallEndedEvent, and CallRejectedEvent