It's a long time since I wanted to post some info concerning memory on this blog, but I always been confused on where to start from.
To take away any doubt, let's start from scratch. Even amongst the most seasoned DBAs there is some confusion about memory , so we should try first to clarify these.
Starting with what is already available over the internet, so far the best blog I found you should consider starting with if you are a newbie in the "memory world", is the following:
PAE and /3GB and AWE oh my...
http://blogs.msdn.com/chadboyd/archive/2007/03/24/pae-and-3gb-and-awe-oh-my.aspx
For any further detailed information on SQL server memory internals, Slava Oks's WebLog (http://blogs.msdn.com/slavao/default.aspx) is what you need.
To summarize (from the SQL Server point of view)
1) With default settings:
Each process will be assigned memory split between:
Physical Memory - user-mode - therefore max 2GB (max depending on phy mem or other apps using the same space) + Disk (Paged)
2) Same (nearly) happens with \3GB.
Each process will be assigned memory split between:
Physical Memory - user-mode - therefore max 3GB (max depending on phy mem or other apps using the same space) + Disk (Paged)
3) With \PAE and AWE
PAE\AWE-aware processes will be assigned up to 64GB of memory (depends on Windows Edition) split between:
Physical Memory - user-mode - therefore max 2GB or 3GB depending on \3GB option (see rule of thumb below) + Physical Memory (Additional) + Disk (Paged)
Rule of Thumb
If your system has < 4 GB - use only /3GB
If your system has > 4 GB and < 16 GB - use /3GB + /PAE + AWE
If your system has > 16 GB - use /PAE + AWE
Now then, so why considering x64 Architecture if we have AWE?
The use of SQL Server (32-bit) with AWE has several important limitations. The additional memory addressability is available only to the relational database engine’s management of database page buffers. It is not available to other memory consuming database operations such as caching query plans, sorting, indexing, joins, or for storing user connection information. It is also not available on other engines such as Analysis Services.
For more detailed information, refer to:
Advantages of a 64-bit Environment
http://www.microsoft.com/sql/techinfo/whitepapers/advantages-64bit-environment.mspx
What about max_server_memory and min_server_memory?
By default, SQL Server can change its memory requirements dynamically based on available system resources. Which means, it can use the amount of memory specified between min_server_memory and max_server_memory.
Use min server memory to guarantee a minimum amount of memory available to the buffer pool of an instance of SQL Server. SQL Server will not immediately allocate the amount of memory specified in min server memory on startup. However, after memory usage has reached this value due to client load, SQL Server cannot free memory from the allocated buffer pool unless the value of min server memory is reduced.
Use max server memory to prevent the SQL Server buffer pool from using more than the specified amount of memory, thus leaving remaining memory available to start other applications quickly.
Usually (underlined, yes it is underlined) you should leave these settings at the default value, BUT the following considerations\exceptions apply:
- As there is a short delay between the start of a new application and the time SQL Server releases memory, using max server memory prevents this delay and may give better performance to the other application.
- With SQL Server 2000 AWE or SQL 2005\2008 AWE on Windows 2000, memory is not managed dynamically. This means, min server memory is ignored and max server memory is never released so must be set (underlined again).
Min server memory and max server memory are advanced options. If you are using the sp_configure system stored procedure to change these settings, you can change them only when show advanced options is set to 1. These settings take effect immediately (without a server stop and restart).
For more info:
Enabling AWE Memory for SQL Server
http://technet.microsoft.com/en-us/library/ms190673.aspx
A general misconception when it comes to transaction log management, is that the transaction log gets automatically TRUNCATED (underlined, as I am not saying SHRINKED!!!) when a full database backup is performed.
This is completely untrue, and if you just don't believe it, just open Management Studio, right click your DB, select task > backup, select backup full and then switch to options... well, as you can see, the "truncate the transaction log" checkbox is greyed out - not an option - indeed.
*
Obviously, TRUNCATING the transaction log is something you must do as a DBA, as if log records were never deleted from the transaction log, it would eventually fill all the disk space that is available to the physical log files.
So question is WHEN does it get TRUNCATED?
Well, except when delayed for some reason, log truncation occurs automatically as follows:
- Under the simple recovery model, after a checkpoint.
-
- Under the full recovery model or bulk-logged recovery model, after a log backup, if a checkpoint has occurred since the previous backup.
For more info:
Transaction Log Truncation
http://msdn.microsoft.com/en-us/library/ms189085.aspx
Therefore, if you are under full of bulk logged recovery mode - you have two options:
- Backup the transaction log - so that it will get automatically truncated (STRONGLY suggested)
- Force the truncation (...)
Now when you actually go for the STRONGLY suggested option :-) i.e. you backup your transaction log and it is actually automatically truncated, this has actually a good consequence, which is let's say that your last backup is corrupted, you can still go back to the one before and recover all the way through to your favourite point in time :) yay!
OK now, what's the difference between TRUNCATE and SHRINK (http://msdn.microsoft.com/en-us/library/ms178037.aspx)? Think it like a box full of books. Truncate takes out the books but the size of the box is still the same, ready for new books (same amount) to be stored in. Shrink makes the box smaller and then when you actually have to store new books well, you will have less storage space - and then you will have to autogrow - therefore you'll be hitting performances (that's actually very good idea, I would like so much an autogrow luggage for my trips).
- Beatrice Nicolini with the contribution of Norm Eberly- aka "he"- Senior PFE -
Just being discussing recently the Backup\Restore best practices (related to corruption) and wanted to share some information.
SQL Server Backup\Restore in SQL (when actually done directly from SQL, not from a 3rd party application - I come to that in a second) offers many options which are:
- Checking the backup consistency while performing the backup
- Checking the backup consistency after the restore (therefore by running DBCC CHECHDB on the restored Database)
- Checking the backup consistency with the restore command without actually performing a restore
Everything is very well explained in this article from (surprise surprise...) Paul Randal:
Oh no – my backup is corrupt too! Help!
http://blogs.msdn.com/sqlserverstorageengine/archive/2007/03/05/oh-no-my-backup-is-corrupt-too-help.aspx
Now, with a 3rd party application things are a bit different as you need to stick with the options that it gives to you.
I've just checked Litespeed options (as an example) and all that I can find is a "Verify Backups" option in the restore wizard.
Now this means that
- you won't be able to check backups when actually creating a backup
- you don't have anything similiar to WITH VERIFYONLY, so you need actually to restore your database to check consistency of your data
This leaves you with the two options:
- Restore with the "Verify Backups" option provided from the Wizard
- Restore and then run DBCC CHECKBD
I am not sure which one would be more efficient. I would guess all that the "Verify Backups" option does is actually to automatically run DBCC CHECKDB but happy to be contraddicted.
Any case, rule of thumb is to ALWAYS DBCCC CHECK your databases (daily) and ALWAYS CHECK YOUR BACKUPS (daily would be best but I already know the opinions on this... say weekly). How- is up to you!
- Beatrice Nicolini -
I've posted a blog entry some time ago about Microsoft recommendation for SQL Server SP2 builds: SQL Server 2005 SP2 - Recommended Build?
Last week Microsoft has released a new SecurityBullettin (MS08-040 - Vulnerabilities in Microsoft SQL Server Could Allow Elevation of Privilege) which while we're waiting for the release of SP3, changes Microsoft position about recommended builds as follows:
- SQL Server 2000 SP4 minimum recommended build is now 2273 (which includes 2187 whch was the old recommended one)
- SQL Server SP2 minimum recommended build in now 3068 (which includes 3054 which was the old recommended one)
Just a couple of notes concerning SQL Server 2005 as things can become a little bit confusing .
Minimum recommended build is 3068, but for example you cannot apply it if your build is between 9.00.3150 and 9.00.3230. In that case you'll have to use KB948108 which will take you to 3233.
Also, if you have decided to keep your instances up to date with the SQL Server 2005 Cumulative Updates, you don't have to apply anything in case you are already on CU7 - build 3239 or CU8 - build 3257 (or above, in the future :-)).
More info:
Microsoft Security Bulletin MS08-040 – Important
http://www.microsoft.com/technet/security/bulletin/ms08-040.mspx
MS08-040: Vulnerabilities in Microsoft SQL Server could allow elevation of privilege
http://support.microsoft.com/kb/941203
- Beatrice Nicolini -
I don't often blog about our team initiatives, but here's one which is very important and we need the most help with.
It's like that famous slogan... "every little helps" ;-)
Local Software Engineer to race through tropical rainforest on a bicycle
15 PFEs of Microsoft are pedalling a massive 420km across Madagascar to raise funds for the charity Computer Aid International by participating in the Madagascar Cycle Challenge (27th September – 5th October).
The grueling bike ride will take them across one of the most ecologically rich and unique countries on the planet, racing on tarmac roads and dusty red-earth off road trails. Far away from the modern comforts of daily life, this will be an unforgettable experience, which is also helping Computer Aid International deliver refurbished computers to schools in the area.
Madagascar is the 4th largest island in the world, located in the Indian Ocean, 400km west of Mozambique on the coast of Africa. Famous for its evergreen rainforests, Madagascar has a diverse animal, plant and aquatic life, said to rival the Amazon in its diversity.
During the 5 day cycle challenge the 15 will take time out to visit a rural school in the village of Isaingy, where Microsoft engineers are helping to deploy 10 computers donated by the Digital Pipeline, a charity which champions the refurbishment and redeployment of donated PCs to serve the educational needs of communities in the developing world.
The Microsoft team’s goal is to raise over £40,000 (€50,000) in sponsorship monies; enough to fully equip 15 schools in Madagascar with a purpose built Computer Lab.
To help this initiative you can refer to:
http://www.justgiving.com/msmadagascar
Rob Elliott - UK
Jane Lewis - UK
Sam Hassani - UK
Lee Marsden - UK
- Beatrice Nicolini -
As a second tool to assess your system configuration, today I am going to post about SQL Server BPA (another acronym!) aka SQL Server Best Practices Analyser (better).
We have 2 versions available:
- one for SQL Server 2000 (http://www.microsoft.com/downloads/details.aspx?familyid=b352eb1f-d3ca-44ee-893e-9e07339c1f22&displaylang=en)
- one for SQL Server 2005 (http://www.microsoft.com/downloads/details.aspx?FamilyId=DA0531E4-E94C-4991-82FA-F0E3FBD05E63&displaylang=en)
And no, I hadn't forgotten about 2008. In 2008 there won't be a standalone BPA tool but there will be something much much better, but for this you have to wait till next blog post (Assess your System (Part3of3)) :-)
1) Before we start talking about what is checked\performances impact etc etc I want to comment which version you should choose when assessing your system.
Given that:
- 2000 BPA requires a 2000 DB to store the data to be analyzed and can only assess a 2000 DB
- 2005 BPA requires a 2005 DB to store the data to be analyzed but can assess both a 2000 DB and a 2005 DB plus comes with additional features and checks
...it would be better to use the 2005 version even when assessing a 2000 implementation, by connecting remotely from another installation.
2) 2005 BPA new Features
- You can scan also SSAS, SSRS and SSIS on your 2005 implementations. You can only scan the DB Engine on your 2000 implementations.
- Auto Update Framework- Every time BPA is started, it cheks on the Microsoft website if rules have been updated or new rules added
- Command line version (not available in 2000 BPA)
Other new features can be found at:
SP2/BPA Frequently Asked Questions http://blogs.msdn.com/sqlrem/archive/2007/01/12/SP2-and-BPA-FAQ.aspx
3) What is Checked?
Best place to look at to have a comprehensive list of the checks done is the help tool which comes with BPA. There is all the information you might be interested in.
4) Performances Considerations
You are retrieving data from your target SQL Server instance, inserting this data on the BPA database and then analysing this data. Guess what? You need a bit of RAM and a quite CPU to perform calculations :-)
Therefore, as you can install the tool remotely, better having it on you local machine, together with the BPA database.
Hope this helps!
- Beatrice Nicolini -
Today I want to post about three very useful free tools from Microsoft which can assist you in automating the process of assessing your systems:
- MBSA (Microsoft Baseline Security Analyzer)
- SQL BPA (Best Practice Analyzer) for SQL 2000 and 2005
- Policy Management (automatically included in SQL 2008 and definitely more than just a tool to access your system vulnerability but I would define it as a management feature which allows to define and enforce policies for configuring and managing SQL Server across the enterprise)
Today we are starting with MBSA (latest version is 2.1 and can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=F32921AF-9DBE-4DCE-889E-ECF997EB18E9&displaylang=en ).
This tool gives you the ability to assess the administrative vulnerabilities present on one or multiple computers and then generates a report that contains details for each computer about the security checks that MBSA performed, the results, and recommendations for fixing any problems.
While BPA and PM are just looking at your SQL Server installation (Security+Best Practices), MBSA performs the following checks:
- Check for Windows administrative vulnerabilities
Scans for problems with the way that Windows is configured on the target computer.
Tests the passwords of local user accounts to determine whether any are blank or have other problems that might allow them to be guessed easily.
- Check for IIS administrative vulnerabilities
Checks for Internet Information Services (IIS) administrative vulnerabilities. When scanning servers running IIS, the computer running MBSA must have the Common Files installed for the highest version of IIS to be scanned.
- Check for SQL Server administrative vulnerabilities
Checks for administrative vulnerabilities on each instance of Microsoft SQL Server, Microsoft Data Engine, or Microsoft SQL Server 2000 Desktop Engine (MSDE) running on the target computer.
- Check for SQL Server administrative vulnerabilities
Checks for missing Microsoft Windows and Microsoft Office updates.
At startup, you can specify which of these options you want to check:
Results are stored on the computer on which MBSA is installed, in the SecurityScans folder of the user's profile (%userprofile%\SecurityScans) by default.
If you want to schedule MBSA scans, or have a standardised set of options to scan, there is a command line version included in the download, called mbsacli.
Running this tool on your systems, at least once every 6 months, is a recommended best practice and will help you maintain your systems secure. Personally, I would advice - prior to scan - always check if a new version has been released on the Microsoft Website.
- Beatrice Nicolini -
After my follow-up post about our SQL Server 2008 event in TVP, where I've presented about SQL Server 2008 Data and Backup compression (well, actually, I did made another last minute presentation on behalf of a friend on SQL 2008 Upgrade :-)), I've been asked to post my slide deck on SQL Server 2008 Data and Backup Compression.
Unfortunately, this is not feasible, therefore I thought to post some of the information I've given during the session.
Compression in SQL Server comes in different flavours, and as I've realized during my presentation very few people (only 1 out of I believe 62?) know that we have already some kind of data compression which was released together with SQL Server 2005 Service Pack 2, called Vardecimal Storage Format (http://technet.microsoft.com/en-us/library/bb508963.aspx).
This type of compression allows you to store decimal and numeric data in the variable portion of the row instead that in the fixed portion.
The compressio ratio you are going to achieve depends on your specific data, but is easy to evaluate in advance by using a simple store procedure:
sys.sp_estimated_rowsize_reduction_for_vardecimal ‘<table>‘
Before we move on to the options available in 2008, let me summarize few points that apply both to 2005 SP2 compression and 2008 Compression:
- As said for 2005, the compression ratio you are going to achieve depends on your specific data, but both 2005 and 2008 come with a stored procedure which will allow yourself to estimate which ratio you are going to achieve
- Compression allows to reduce the disk space required for storing your data but by using compression you will see as well:
- an improvement in memory utilization
- better performances for I/O bound workloads
- On the other hand, you will have to pay all these benefits through CPU utilization, therefore in most of the cases you will see a small amount of CPU degradation
- All compression types are only available in Enterprise edition
- Application do not need to be changed (data is presented to applications as before)
OK So what about SQL Server 2008 then?
2008 comes with two new types of compression:
- ROW Compression (http://msdn.microsoft.com/en-us/library/cc280449(SQL.100).aspx) is very similar to Vardecimal Storage Format in SQL 2005 SP2 but the data-types that you can compress are more (basically all the types that are based on numeric so also datetime and money).
Vardecimal storage format is still supported in 2008 however, because row-level compression achieves the same goals, the vardecimal storage format is deprecated.
- PAGE Compression (http://technet.microsoft.com/en-us/library/cc280464(SQL.100).aspx) which includes Row Compression plus two additional compression algorithms, called
- column prefix and
- page dictionary.
Without going into the details of the two algorithms, (which if you are interested you can find on the SQL Server Storage Engine Blog - Data Compression Series) what you need to know is that while ROW compression looks at a single piece of data at a time, and compress it, the two other algorithms included with PAGE compression look at 'recurrences' in the column\page, at a byte level, therefore you are going to achieve great compression ratio every time your bytes are repeated in your page (bytes, not data).
As usual, you have a stored procedure to estimate the compression ratio:
sp_estimate_data_compression_savings
[ @schema_name = ] 'schema_name'
, [ @object_name = ] 'object_name'
, [@index_id = ] index_id
, [@partition_number = ] partition_number
, [@data_compression = ] 'data_compression'
[;]
Another thing worth knowing is that you have control over the objects you want to data-compress: therefore you can decide if you want to compress one single index (and leave the others un-compressed) or a single partition.
What about SQL Server 2008 Backup Compression? I bet this will be one of the major driver for the adoption of SQL 2008 as I know that most of the customer were looking forward for such a feature already since 2005.
Well, obviously Backup Compression will save the storage space required for your data (whoooooop!) and we are talking of compression ratios of 5:1, therefore completely comparable to most 3rd party software you know on earth :-). Official data is not available yet, but I will post some info as soon as I will get hold of it!
Interesting fact is that actually, the run time of your backup\restore operation is going to decrease. If you want some numbers, have a look to this article from Paul Randal (SQL Server 2008: Backup Compression CPU Cost ) which exposes some interesting results from some tests done on our lovely AdventureWorks database!
Well, this was a very long post to write so I hope to have included most of the relevant information re. Compression in SQL Server 2008.
If you have any question, just drop me a comment and I will reply!
- Beatrice Nicolini -
I've already blogged some time ago about Microsoft recommendation for SQL Server Storage Best Practices.
Is there anything else you should be aware in order to maximise the performances of your disk subsystem?
Oh yeah. Volume Alignment (Or Sector Alignment) and NTFS Allocation Unit Size can provide significant benefits to your disk performances (30% throughput increase on average) and you should definitely consider implementing both on your box.
Volume Alignment (Or Sector Alignment)
Windows Xp, Windows Server 2000, Windows Server 2003, instantiate 63 hidden sectors in all new partitions.
As in a default situation we have:
- NTFS default format size of 4KB.
- 64 512B sectors > 32KB per track, so there are 8 format “chunks” per track.
This means that when we write the first data to a new partition we are actually writing some bytes in the first partition and some other on the next one!
Therefore, every time we are reading\writing our data, we need to access two tracks, and the mechanic of the disks is going to heavily impact on our performances!
To avoid this issue, yous hould then consider implementing Volume alignment, commonly referred to as sector alignment on the file system (NTFS) whenever a volume is created on a RAID device.
More info can be found at:
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx#EPAAC
http://support.microsoft.com/default.aspx?scid=kb;EN-US;929491
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1262122,00.html#monitoring
NTFS Allocation Unit Size
When formatting the partition that will be used for SQL Server data files, it is recommended that you use a 64-KB allocation unit size for data, logs, and tempdb.
Be aware however, that using allocation unit sizes greater than 4 KB results in the inability to use NTFS compression on the volume.
Test Results
Following are the results of some tests performed on Latency & Duration on a RAID 10, 64KB file allocation unit.
- 6 disks vs. 8 disks
- Not Aligned vs. Aligned
- 6 aligned disks performed as well as 8 non-aligned disks.
- Thus, efficiencies of ~30% were achieved.
- Beatrice Nicolini -
Hi all,
Just wanted to thank all the attendees that participated to yesterday's event on SQL Server 2008 in TVP - Reading.
We've received great feedback on the content of the day, and I really hope everybody went back home (for some of you I heard it was quite a long way) sure that SQL Server 2008 is a great product full of new features and enhancements which are just what you need for your business activities.
I just want to follow-up some questions which I've received during the event, and leave some links to review if you want to further learn about Data and Backup Compression.
Questions:
"Data compression is an enterprise only feature. Is it possible though to restore compressed backup on standard?"
Though creating compressed backups is supported only in SQL Server 2008 Enterprise Edition and later, every SQL Server 2008 or later edition can restore a compressed backup.
"Are there some guidelines to tune performances of backup compression"?
Yes, one interesting article from Technet and from SQL CAT:
- Tuning the Performance of Backup Compression in SQL Server 2008
http://sqlcat.com/technicalnotes/archive/2008/04/21/tuning-the-performance-of-backup-compression-in-sql-server-2008.aspx
- How to: Use Resource Governor to Limit CPU Usage by Backup Compression (Transact-SQL)
http://technet.microsoft.com/en-us/library/cc280384(SQL.100).aspx
Useful information:
Reducing Database Size by Using Vardecimal Storage Format
http://technet.microsoft.com/en-us/library/bb508963.aspx
Creating Compressed Tables and Indexes
http://msdn.microsoft.com/en-us/library/cc280449(SQL.100).aspx
SQL Server Storage Engine - Data Compression Series
http://blogs.msdn.com/sqlserverstorageengine/archive/tags/Data+Compression/default.aspx
Backup Compression (SQL Server)
http://msdn.microsoft.com/en-us/library/bb964719(SQL.100).aspx
SQL Server 2008: Backup Compression
http://www.sqlskills.com/blogs/paul/2007/09/20/SQLServer2008BackupCompression.aspx
SQL Server 2008: Backup Compression CPU Cost
http://www.sqlskills.com/blogs/paul/2008/01/09/SQLServer2008BackupCompressionCPUCost.aspx
Download the last CTP
https://connect.microsoft.com/SQLServer/content/content.aspx?ContentID=5395
For any additional question, please contact myself directly at beatrice.nicolini@microsoft.com and read our team blog at http://sqlblogcasts.com/blogs/thepremiers/default.aspx.
- Beatrice Nicolini -
On the 2nd June 2008 Microsoft announced the launch of Microsoft Store in the UK.
Microsoft Store will bring together a wide range of our consumer products for the first time, allowing customers to explore and purchase through a single, online experience.
Customers have now the ability to buy Windows, Office, Expression via electronic download. This offers UK consumers the ability to use their software almost immediately as well as giving them piece of mind by knowing that their software and licence will be securely stored online.
To start now, try it at http://www.microsoftstore.co.uk/!
As you might (or might not?) know, since SQL Server 2005 the SQL Server team has moved away from the current priority-driven hotfix release model to a scheduled delivery model, called Incremental Servicing Model (for more info: http://blogs.technet.com/beatrice/archive/2007/07/11/incremental-servicing-model.aspx)
This means that now we are using, together with the standard hotfixes we were used to, Cumulative Updates which will include all On-Demand Hotfixes that have been released leading up to the delivery of the cumulative update, as well as fixes created for less critical problems that don't meet the urgency requirements of the On-Demand Hotfixes.
These are released every 2 months, and latest one is CU7: http://blogs.technet.com/beatrice/archive/2007/07/11/incremental-servicing-model.aspx
Now, as Microsoft states:
"This Cumulative update is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems. This cumulative update package may receive additional testing. Therefore, if you are not severely affected by any of these problems, we recommend that you wait for the next SQL Server 2005 service pack that contains the hotfixes in this cumulative update package. "
Ok therefore, should you remain on standard SP2 (Build 3042)?
Nope.
Minimal recommended build for SQL Server 2005 SP2 is either 3054 or 3159 and NOT the standard 3042.
There is a well-documented blog post from Bob Ward (Microsoft SENIOR ESCALATION ENGINEER) which explains whether you need 3054 or 3159, and I recommend you to have a look:
SQL Server 2005 Service Pack 2 (SP2) Re-release and post fixes explained
http://blogs.msdn.com/psssql/archive/2007/04/06/post-sql-server-2005-service-pack-2-sp2-fixes-explained.aspx
- Beatrice Nicolini -
I blogged some time ago about PAL (Performance Analysis of Logs (PAL) Tool), a great tool from CodePlex which allows you to quickly and automatically analyze a set of Performance Monitor logs and to easily spot which counters are "misbehaving" in your environment.
This week I want to post about another useful tool, SQL Nexus, always downloadable from CodePlex, which instead makes it easier to analyze data collected from:
How does in work
- You need SQL 2005 in order to run the tool (it will import your data in a user database called - without surprise - sqlnexus)
- Feed the tool with the data you want to analyze (SQL Trace files; T-SQL script output, including SQL DMV queries; and Performance Monitor logs)
- Once the data is loaded, you can fire up several different charts and reports to analyze it:
- Blocking and wait statistics
- Bottleneck Analysis
- Profiler Trace Analysis
The latest version can be found on the official page: http://www.codeplex.com/sqlnexus
More information can be found in Ken Henderson's Blog: http://blogs.msdn.com/khen1234/archive/2007/09/23/random-thoughts-on-my-trip-to-the-conference.aspx
- Beatrice Nicolini -
I've just realized how poorly documented is this great functionality that has been introduced in SQL Server 2005.
On the Microsoft Website, all you can find is this article (http://technet.microsoft.com/en-us/library/ms175513.aspx) and few more information.
Looking outside the Microsoft website, the most complete article I've found up to now, is the following:
Searching for a Trace
Solving the mystery of SQL Server 2005's default trace enabled option
By: Kalen Delaney
http://www.sqlmag.com/Articles/ArticleID/48939/pg/1/1.html
which I suggest you to have a look for more information.
Just to add my bit of experience on top of this, let me summarize some major points about this great functionality:
1) What is the Default Trace in SQL 2005?