Home / server / Questions / 142452
In Process
stacker
Asked: 2010-05-17 15:28:57 +0800 CST

IIS 7.5 log to: sql server vs file

  • 772

I want to know if get IIS to log directly to the sql server is resource costive, and a better solution maybe generate log files, and each hour import this files to sql server.

Does it VERY big cost to log to sql server each request directly? The pages are open connection to the database anyway for each request.

logging log-files sql-server-2008 iis-7.5

2 Answers

  1. Start here http://weblogs.asp.net/steveschofield/archive/2007/12/20/iis7-post-57-how-to-setup-odbc-logging-in-iis-7-0.aspx

    Personally I haven't ever done this; rather I have setup a script to import old IIS logfiles into a SQL DB with Logparser.

    Here is the PowerShell script I use

    ### Parameters ###
$iisLogLocation = "$env:systemdrive\inetpub\logs\logfiles"
$logParserLocation = "C:\Program Files\Log Parser 2.2"

### Main Script ###
$files = Get-ChildItem $iisLogLocation -Recurse |
    Where-Object{$_.LastWriteTime -le (Get-Date).Subtract((New-TimeSpan -Days 7))}

if ($files.Count -gt 0){
    foreach ($file in $files){
        $logParserArgs = @"
"SELECT LogFilename, LogRow, TO_LOCALTIME(TO_TIMESTAMP(date, time)), s-sitename, s-computername, s-ip, cs-method, cs-uri-stem, cs-uri-query, s-port, cs-username, c-ip, cs-version, cs(User-Agent), cs(Cookie), cs(Referer), cs-host, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO IisLogData FROM $($file.FullName)" -o:SQL -server:.\sql01 -database:logs -ignoreIdCols:ON -fixColNames:ON -maxStrFieldLen:1000
"@
        Push-Location $logParserLocation
        LogParser.exe $logParserArgs
        Remove-Item $file.FullName
        Pop-Location
    }
}
    • 1

  2. The worst thing about writing your IIS logs directly to SQL server instead of a text file is that there are now two real points of failure: your IIS instance and a database server.

    If you start database logging to the same machine that is running the database for your production application, you are taking resources away from that application. Databases can block, they can run out of space (admittedly so can your hard drive, but still), they need more regular maintenance, etc. I.e., they can fail for reasons totally unrelated to your application. And if it fails, then the log data is just gone.

    Opening and writing text file logs is very low overhead. commandbreak's script is exactly the sort of short, simple thing that will take care of moving the log to a database; and if the db is down the log is still there.

    • 1