1. Backup all the user and system databases (with checking integrity of the backup)
2. Check the health status of the user databases (DBCC CHECKDB)
3. Check if this specific SP has some issues, bugs, Connect items

If you dont followi the steps it is not necesary to have a problem. But statistically it happens at some time.

Like in this case, when I am shaing my experience in applying SP2 of SQL Server 2008 R2: http://maginaumova.com/master-database-error-after-applying-sql-server-2008-r2-sp2/

Good luck and thanks for reading! :-)

MS Days 2012 was kind of a point of return to the SQL Life. I had two presentations and full room of attendees to which I am really thankful. The first presentation was “Top 10 things you shouldn’t do as a database developer”. I was thinking about such a presentation for a long time. On every SQL Server PTO project I phased some kind of coding problem that shouldn’t be a part of a good database project. Well, I realize that those practices are very hard to group in a list of 10, even 100, but its not a number that matters. The important is to show in a no-doubtable way why the respective thing is a bad practice and of course to propose a better solution.

My second presentation was “Optimizing SQL Server 2012 for Private Cloud”. The topic is modern and SQL Server 2012 is part of it also. The important there is not the Cloud part, but Consolidation and Virtualization part – the Cloud preparation phases. Dynamic Memory Support in virtualization, Resource Governor for Multi-Tenancy and Contained databases.

It was yet another great event and I am glad I was part of it!

I will blog some of my presentation’s focal points . “See” you soon

I will try to blog them in next few publications, but let me start with a first one, that I consider as underestimated and not very clear, at the same time very common.

In order to explain what exactly the Hash and Sort warning are and why they should be treated as a signal of a performance problem let me first pay more attention on Expensive Operators in query plans

Expensive Operators

Some operators in query plans have specific resource needs. They need more memory than the others in order to perform their tasks. Such operators are called memory consuming operators and they could make a query more expensive from the resource point of view. Such operators are SORT, SORT DISTINCT, HASH JOIN, HASH AGGREGATE.

At compilation time, based on estimated number of rows that the operator will have as an input, the QP calculates the number of pages in memory that this operator needs in order to execute. When a query has a memory consuming operator the QP calculates the memory needed to execute the query as a Memory Grant. The Memory Grant is a value that contains the sum of all pages needed by all expensive operators in order to execute the query plan. Occasionally, the query can become very expensive, especially when those operators process large numbers of rows. For example the Sort operator is very expensive because it’s “costs” is proportional to number of rows that have to be sorted, respectively the number of pages that those rows fit.

select so.SalesOrderID, so.ModifiedDate
      from  Sales.SalesOrderDetail so
      where so.ModifiedDate between '2001-07-01 00:00:00.000' and '2002-02-01 00:00:00.000'
      order by so.SalesOrderDetailID
      option (maxdop 1)
     

We have a SORT operator which requires 1344 pages of memory in order to perform the sorting of data. The overall Query Memory required is 1344*8K=10.5MB

If I remove the need for SORT operator (you can comment ORDER BY clause to test that), then my query plan would be

Note that I don’t have Memory Grant as part of the query plan description of the root operator.

In both cases the execution plan is 16 Bytes in cache.

The key points

• Using Sort and hash operators in the query plan requires additional query memory or workspace memory, outside of the memory needed to store execution plan
• The Memory Grant is a an allocated query memory.
• The QP calculates Query Memory at the compilation time, but the real usage of this Memory is during the query execution.

How a query with expensive operators is executed

Query memory is allocated outside of the buffer pool. The amount of space available for query memory allocation is dynamically managed between 25% and 75% of non-AWE buffer pool (only data pages can use AWE mechanism for page allocation). 5% of the Query Memory is reserved for small queries (queries with low costs). No query can take more than 20% of the Total Query Memory. There are 5 query Memory Grant queues as a mechanism to manage expensive queries and to allow less expensive queries to run. The queues are organized based on query cost. Every query containing hash/sort operators has to pass trough the global grant queue, where it is put in its respective queue based on its costs. Queues are served on first come first serve basis. There is a little probability more than a couple of expensive queries from a large cost queue to execute at the same time, they probably  will execute one after another.

After such a query is compiled and the plan is cached, there comes the step of query execution or the moment of truth. At this time the query needs the memory to be allocated. There are couple of scenarios that could happen here. If there is no available memory  or there are other expensive queries with similar cost (on the same queue) executing at the same time, then the query waits in the Memory Grant Queue.

If the query reaches the wait time threshold (the Query Wait Option on SQL Server Level), then the query times out. You can start query again later, but obviously this is a signal that you have more queries with expensive operators than your server can perform. So the possible focus for further troubleshooting is to try to optimize queries and reduce their expensive operators trough proper indexing, reconsiderations of using ORDER BY clause,  , increase server memory could be also an option (that is too broad topic to discuss here)

If the query gains the memory the query execution starts. So far so good. But the real moment of truth comes here, because this is the moment of test if the QP calculations and the Memory Grant is enough. What are the possible scenarios then?

The Memory Grant is not enough for the query to execute smoothly.

This is when the Hash and Sort Warnings appear. Why would this memory grant be not enough? Because there is a misunderstanding and respectively a miscalculation of the memory needs at compilation time and at query execution time. Note that I don’t mention that the problem is in memory shortage/misconfiguration or that you have to add more memory to your server. Well, that could be the case, but the experience of Hash and Sort warnings alone doesn’t necessary mean than there is a performance problem and resource shortage. Why there could be miscalculations and when?

Imagine that you have a query plan cached  with a specific parameter value that QP get at the compilation time, and actually based on that value it creates the plan. You execute the query (trough stored procedure, sp_executesql with parameters for example) and you provide different parameters value leading to differences in selectivity and the result set (a lot more rows for the sort operator input for example).

Using the cached plan and respectively the same Memory Grant is not enough for the memory consuming operators to perform their tasks.

To illustrate exactly what happens, let’s focus on some examples. Lets create a very simple procedure called SalesOrderSelect. I am going to rely on procedure plan caching that is provided in SQL Server, that is why I am using a stored procedure here rather than ad-hoc select statement.

create proc SalesOrderSelect
@ModifiedDateFrom datetime,
@ModifiedDateTo datetime as

begin

      declare @SalesOrderID int,
              @ProductID int,
              @ModifiedDate datetime

      select so.SalesOrderID, so.ModifiedDate
         from  Sales.SalesOrderDetail so
         where so.ModifiedDate between @ModifiedDateFrom and @ModifiedDateTo
         order by so.SalesOrderDetailID
      option (maxdop 1)

      end

go

No lets execute the procedure for the first time with the parameters defining the interval of 6588 rows, which is about 5% of the rows in the table. The first execution generates the procedure execution plan for this specific parameter values, and this plan is cached in memory.

exec SalesOrderSelect '2001-07-01 00:00:00.000', '2002-02-01 00:00:00.000'

Now lets execute the stored procedure again, but defining a larger result set. Let’s also profiler the query, including the Hash and Sort Warning events from the Errors and Warning Event group

exec SalesOrderSelect '2001-07-01 00:00:00.000', '2003-02-01 00:00:00.000'

The query returns 27405 rows, about 4 times more that in the first execution. And because it is using the same execution plan that is cached in memory, the resources for the query are the same, including the Memory Grant parameter. This time, the SORT operator must perform the sorting on 4 times more rows than in the first execution, using the same amount of Memory (10.5MB). Because of that the Engine raises the Sort Warnings Event.

The sort operation doesn’t fit in memory and continue sorting using the tempdb database and performing multiple passes over the data that are required to be sorted. This is the reason of performance degradation. The same applies to hash operators when the memory grant is not enough – the hash warning indicates that the hash recursion has occured , which is the build input doesn’t fit in the memory granted, resulting in  the split of input into multiple partitions that are processed separately. If any of these partitions still do not fit into available memory, it is split into subpartitions, which are also processed separately. This splitting process continues until each partition fits into available memory or until the maximum recursion level is reached (displayed in the IntegerData data column). Hash bailout occurs when a hashing operation reaches its maximum recursion level and shifts to an alternate plan to process the remaining partitioned data. You can imagine that a query could be very slow once reaching that case.

The Memory Grant is more than it is needed

What if we have an opposite case, where we execute the query with a cached plan using more restrictive clause, such ending up with more memory allocated then it is actually needed.

In order to do that I am recompiling the stored procedure and executing it after that

exec sp_recompile SalesOrderSelect

go

go

Note that the Memory Grant is calculated as 3904 pages or approx 31MB. If I execute the query using the smaller interval, I am going to need 10.5MB of memory. The query will not raise sort warning, but I am going to waste approx 20MB of the memory grant, my query will going to use 3 times more memory that it actually needs, and probably my query will go to inappropriate queue. .

What are the cases when Hash and Sort Warnings can occur

All the Cardinality errors cases - http://msdn.microsoft.com/en-us/library/ms181034.aspx – look at the cases when QP cannot accurately calculate cardinalities, I am not going to copy them here. If the QP cannot accurately calculate cardinalities of query plan operators, then it makes errors in calculating the query memory, sometimes even choosing the appropriate operator. When the QP have no idea what is the cardinality , for example if you have user-defined function whose argument is not a constant value in the where clause, then the QP has to guess and makes assumptions depending on the comparison operator (9-30% selectivity of the clause), which could be totally wrong in  your case. (that is a good candidate for a next post)

Parameterized queries and stored procedures when the parameter values are very different leading to different selectivity of the query. This was the case I use in this post as an example.

The Solution

Track events first. I am using the RML tools for monitoring, and readtrace after that to process traces, or SQL Nexus. You can run RML to capture the detailed trace for some period of time depending on your workload or periods of slow system response. Don’t use the Profiler, it will harm your performance. Beside that the RML tools can and will surprise you with how many other thinks you can find happening with your database and workload that could be optimized. Sort and Hash warning appears in the Interesting Event Reports with statements where they occur. Sometimes I work directly with PerfAnalysis database to find out more info that do not appear in the graphical reports. When you find out the statements when the sort/hash warnings occur try to perform the following optimizations:

• make sure statistics are maintained properly on database and object level
• use compile hint, sometimes it is cheaper to recompile on every execution than to pay for sort/hash warnings, you can use plan guides if you don’t want to change your code
• don’t confuse parameters and variables and make sure you have the right values at the compile time provided to the QP
• make sure to eliminate/reduce cardinality error cases mentioned in the above link. Most of them need rewriting the query
• reduce ODRER BY if you can

Thanks God (and Doncho & Geri from MS) that we had catering after that

The link for the presentation:  http://cid-7fb6c71238ff60f7.office.live.com/browse.aspx/.Public/Presentations?uc=1

Enjoy, and see you next time!

There are two requirements for the Denali CTP1 installation that you better pass before you got two separate stop errors on configuration and installation check steps

1. Microsoft .NET Framework 3.5 SP1 Update for Windows Vista and Windows Server 2008

2. Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0)

If you miss the first requirement then you will get the following message in the beginning of your installation at the Setup Support Rule Check.

If  you miss the second requirement you will get the error that Windows Power Shell 2.0 is not installed after you pass the feature selection at the Installation Rules Check.

Because my VM is a DC, I cant use the built-in Windows accounts for services, and I created a separate Domain user account for SQL Services. Your case may be different.

The are some strange rules listed in System Configuration and Installation Configuration Reports:

• BIDS2008InstalledCheck rule checks if any of SQL Server 2008 Business Intelligence Development Studio installation exists. It passed saying that SQL Server 2008 Business Intelligence Development Studio is not installed. Actually I have SQL Server 2008 with all the components Installed.
• Shared Components Upgrade Rule checks whether SQL Server "Denali" CTP1 shared components (such as IS, BIDS, Tools, SSMS, or BOL) are present on the machine, because installing SQL Server "Denali" CTP1 shared components will automatically upgrade the existing shared components. The rule generated a warning message showing that there are one or more shared components of SQL Server "Denali" CTP1 installed on the machine. It warns that installing SQL Server "Denali" CTP1 shared components will automatically upgrade the existing shared components. Actually It is the first time I am doing Denali Installation, so there is no way I am aware of to have its Shared components on the VM.

Changes in the Installation Process

Actually the installation is the same as SQL Server 2008 with very small changes.

There is a new Setup Role page in the installation allowing you to choose the General SQL Server Features that you want to install. If you want to install everything as SQL Services and Shared tools then you can simply choose All Features with defaults service accounts (puts system accounts for Services).

The All features doesn't save you the Features selection box, it just checks all features for you.   

If you want just PowerPivot than you better prepare yourself for a lot of requirements and check for this installation, starting from 64-bit OS and ending with accounts for SQL server is SharePoint Farm requirement.

You can find all the Setup Rules requirements here, but the requirements for PowerPivot for SharePoint Installation are not listed in this link.

I found the following from my Boot strap Report:

I think I am not going to start the PowerPivto for SharePoint soon.

That is shortly the Denali Installation, pretty smart and easy. I am even thinking to repeat it on my laptop, seems that it is safe to play with (i remember those days when I had to prepare a separate and very isolated VM for installing first CTP of SQL 2005 :))

The most interesting and exciting part of playing with the product just begins. I found some new features in the SSMS already  and I like them – the SSMS Add extended events that was a separate installation for 2008 is there, the SSMS itself looks very much like VS 2008. There are new Availability Groups and Integration Services folders that I am starting playing with. I know that there will be major changes to the SSIS, so i hope to find something in CTP1.

Will update you soon :)

The HADR-on features are coming. Even with partial functionality enabled at CTP1 we are happy to have Availability Groups and Read Only Mirror! Let’s play with this CTP! Enjoy:

Download SQL Denali CTP1

View Ted Kummert’s PASS Keynote Video and read the Interview

Waiting to hear your experience :)

· SQL Server Masters Certification Goes Global (the first press release and press video)

· New Path to Microsoft Certified Master: Microsoft SQL Server 2008

· Data sheet (executive summary)

· SQL Server 2008 Microsoft Certified Master (MCM) Readiness Videos

Q: RBS and FILESTREAM Usage, why using the FILESTREAM/RBS functionality in SharePoint delayed?

A: FILESTREAM and RBS are complementary approaches for storage and management of BLOBs and we see them both continuing to evolve.

• FILESTREAM provides a storage option that allows storage, efficient streaming and integrated management of large BLOBs in a SQL database by utilizing the underlying NTFS file system for BLOB storage/streaming. It offers fully transactional access and compatible operations as varbinary(max). The FILESTREAM support is built into SQL Server 2008 Database Engine.
• RBS is a set of  standardized APIs that allow storage/retrieval of BLOBs outside of your main SQL database where a dedicated BLOB store is desirable for various reasons. This uses a provider model for plugging in any dedicated BLOB store that implements these RBS APIs. We have also built an out-of-the-box RBS FILESTREAM provider that allows a deployment to use a SQL Database (local or remote) as a dedicated BLOB store. This provider utilizes the FILESTREAM as the BLOB storage mechanism and ties the two technologies together. SQL Server (RBS) is available as part of the Feature Pack RC0 for Microsoft SQL Server 2008. The download includes a client-side DLL that you can use in your applications and also some stored procedures to install on the SQL Server itself. The RBS RC0 setup program is available for X86, X64, and IA64 computers. It requires the Microsoft Installer 4.5

Download the RBS RC0. Here’s the link: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=089a9dad-e2df-43e9-9cd8-c06320520b40

The RBS team also released a sample application showing the many ways to use this new feature, including:

• Basic store / fetch
• Specifying collections / blob stores for store calls
• Push and pull streaming APIs
• Using the System.IO.Stream APIs to do asynchronous reads from the blob store

This package also includes a sample file provider, in case you do not have an RBS store to test your application. Be sure to install the sample provider (the instructions are available at the CodePlex site) before you try storing and reading blobs.

Download the sample and leave comments at http://www.codeplex.com/sqlrbs

Check the recently created RBS team blog at http://blogs.msdn.com/sqlrbs

Q: How to decide FILESTREAM or In Data Page storage and what are the FILESTREAM advantages?

A: According to BOL use FILESTREAM when:

• You are storing BLOBs with an average size of 1 megabyte or more
• Fast read access is important
• You want to access BLOBs from your application's middle tier code

The advantages of using FILESTREAM are:

• You store and retrieve your BLOBs together with your relational data in a single data store  
• The BLOBs are included in database backups and restores
• Inserting, updating and deleting BLOBs and your relational data happens in the same database transaction
• The 2 GB max size for a varbinary(max) column doesn't apply; you are only limited by the available space on the NTFS file system
• The SQL Server buffer pool memory is not used to operate on BLOBs; in previous versions large BLOBs could consume a lot of this memory
• All BLOB access can be performed from .NET code, allowing your middle tier code to easily work with these objects
• The NTFS file system can save and retrieve large BLOBs faster than SQL Server

Q: How the disk parameters should be setup for the disks where Transaction Log  reside?

A: To answer the question lets clarify some terms which will allow us to be on the same page

Sector Size

The sector size is the smallest physical storage unit on the disk, the minimum data chunk that can be written to disk. . The sector size is a fixed size set by the disk manufacturer. Historically, sector size has been fixed at 512 bytes. (Newer drives make 1KB, 2KB, or 4KB sectors available.)

Stripe Size

The stripe size refers to the unit of data that is written and accessed from a disk in a RAID system. This is a configurable value that is set when designing the storage array system. A smaller stripe size allows data to be distributed to more disks and increase I/O parallelism. Note that the stripe size of a single SQL Server extent (64 KB) is the lower limit. For the same data, a larger stripe size means the data can be stored on fewer disks and decrease the I/O distribution and the degree of parallelism.

File Allocation Unit Size

When hard drives are formatted, the size of the file allocation unit defined by the OS (or user) determines the number of sectors per file allocation unit. The file allocation unit size is known also as cluster size. For example, if the sectors of a hard drive are 512 bytes & a 64KB file allocation unit is defined, the cluster is comprised of 128 sectors.

Partition Alignment

Disk array hardware reports 63 reserved (hidden) sectors, and Windows obediently implements this information, reserving these sectors at the beginning of the first partition of a disk. The master boot record (MBR) resides within these hidden sectors. The compliance by Windows with 63 hidden sectors reported by disk hardware results in misalignment with stripe units, disk controllers, and cache segment lines. In all versions of Windows earlier than and including Windows XP and Windows Server 2003, these reserved sectors do not coincide with fundamental physical boundaries. The result is that single clusters of user data are written across multiple stripe units of the RAID. Every nth operation is affected (n depends on file allocation unit (cluster) size and stripe unit size). Fundamental physical boundaries in disk controllers and other hardware are also violated. (Disk Partition Alignment Best Practices SQL CAT Team Article)

Correlations: Partition Offset, File Allocation Unit Size, & Stripe Unit Size

There are two correlations which when satisfied are a fundamental precondition for optimal disk I/O performance. The results of the following calculations must result in an integer value:

Partition_Offset ÷ Stripe_Unit_Size

Stripe_Unit_Size ÷ File_Allocation_Unit_Size

Of the two, the first is by far the most important for optimal performance.

What is the role of the sector size for the transaction log?

Although SQL Server tries to use the log space as efficiently as possible, certain application patterns cause the log-block fill percentages to remain small. The following extreme example points out the clear difference in the transaction log space requirements as the sector size varies.

  WHILE(@I < 10000)

  BEGIN

    BEGIN TRAN

    INSERT INTO tblTest values (‘A’, @I)

    COMMIT TRAN

    SET @I = @I + 1

  END

- vs -

BEGIN TRAN

  WHILE(@I < 10000)

  BEGIN

    INSERT INTO tblTest values (‘A’, @I)

    SET @I = @I + 1

  END

  COMMIT TRAN

The first example requires SQL Server to write the log records 10,000 times, as each commit is processed. The second example enables SQL Server to pack log records and write all 10,000 inserts and the single commit at the same time.

Calculating the log usage for the examples results in the following approximations.

· By using a 4-KB sector size for the first example, ~40 MB of disk space is used.

· By using a 512-byte sector size for the first example, ~5 MB of disk space is used.

· By using a 4-KB sector size for the second example, ~1 MB of disk space is used.

·   By using a 512-byte sector size for the second example, ~1 MB of disk space is used.

How the 40MB and 5MB disk space comes from - It is 10 000Transactions * 4K or 512byte respectively. With first two examples where we have large number of small transactions all that matters is the sector size. When you have one large transaction, the 1MB of disk space is calculated as just the total amount of data that need to be saved in the log unrelated to the sector size, because SQL Server is able to pack the log records. With smaller number of larger transactions and wrapping inserts you can gain sequential writes up to 64K blocks for writing the Transaction and not wasting log space, and because you have smaller number of transactions you get smaller MB/s and performance benefits.

Not that the example shows how the different sector sizes affect the log size in those particular cases. We however don't have much choice for the sector size because it is set by the hardware vendor. We however do have control for our transaction size and data layer application, and we should prefer to batch such kind of data modification instead of sending them as a separate small transactions.

Transaction Log structures and how they are written

The typical pattern of transaction log workload in OLTPs are sequential Log writes up to 60k and sequential Log reads up to 60k. Operations inside the database generate transaction log records. A log record contain information about data modifications (Prev/Next data pages LSNs, data values modified, transaction information). In the beginning of a transaction a beginning record is created,  and the end of a typical transaction is marked as Commit Record, which indicates that the transaction must be reflected in the database’s data files or redone if necessary. You can easily find all the records for a transaction using the non-documented function fn_dblog

For example executing SELECT *  FROM fn_dblog (NULL, NULL) for the current database, returns the following table result where you can easily see the transaction records for transaction 544 (from row 7 to row 17), the begin transaction record (LOP_BEGIN_XACT), the commit transaction record (LOP_COMMIT_XACT), their size and lot more information. 

As you probably know at least from my previous blog posts for Log Fragmentation, the Transaction Log is a sequential file which contains VLFs – a smallest unit of Log management – making log part active, truncating the log. VLFs are split internally into dynamically sized log blocks, ranging from 512-bytes to 64KB in 512-byte increments, as needed.

When a transaction commits, all the transaction log records should be written to disk, which force the actual physical IO operation. Not every transaction log record is written as a separate IO operation to disk. Log records are grouped into log blogs, which are the unit of a write IO operation in the transaction log. The log block are dynamically sized according to specific internal algorithms, but their size definitely divides to sector size (usually 512) and their max size is 64KB. The log block change can be obtained from Current_LSN Column in the fn_dblog result set as a change in the middle number (000000a2 for the Transaction 544). Note that log blocks have different sizes according to the transaction (Summary of Log Record Length column in Bytes). Paul has a good post showing the importance of transaction size, batching data modification for log block sizes and the resulting TLog IO optimizations. Again the large number of very small transactions as well as the large transactions could affect negatively.

What we can do and what are the configurable values?

We can configure the Stripe Size, File Allocation Unit Size and we have to make sure the partitions are aligned (for OS prior to Windows Server 2008)

We recommend a 64 KB or 256 KB stripe size for most workloads. When the workload includes table and index range scans on tables that are larger than 100 MB, a stripe size of 256 KB allows for more efficient read-ahead.

It is very hard to know in detail the workload and to configure those values in the best possible way. That is why the recommendation exists covering the average workload type and mentioning exceptions.

Small stripe sizes work better for small IO requests because you can process lots of them in parallel using most of your spindles. A large IO request requires large seek time to read only few KBytes on each spindle, so in case your IO requests are large, increasing the stripe size can help to get more throughput, reading lots of data with small costs. Long stripe sizes usually work better in scenarios with not too many parallel requests.

If your IO requests are small and you have large stripe sizes you can end up with a not so good distributed load among the disks, and you cannot evenly utilize lots of spindles you have (in case you have them). You cannot get the maximum throughput because you do not parallel your IO operation. The small addressable unit of the array is the stripe so having very large stripes can hurt performance when storing small files or writing transaction log streams.

The file allocation unit size (cluster size) recommended for SQL Server is 64 KB

An appropriate value for most installations should be 65,536 bytes (that is, 64 KB) for partitions on which SQL Server data or log files reside. In many cases, this is the same size for Analysis Services data or log files, but there are times where 32 KB provides better performance. To determine the right size, you will need to do performance testing with your workload comparing the two different block sizes.

In the absence of an explicit vendor recommendation, use a partition offset that complies with the correlation discussed in the section “Correlations: Partition Offset, File Allocation Unit Size, and Stripe Unit Size”. 64 KB is a common, valid starting partition offset because it correlates well with fundamental physical boundaries in disks, controllers, and cache. Other valid starting partition offsets exist. The Windows Server 2008 default is 1024 KB.

The most important think to consider however are not those configurations. Even when we have those settings as a fact that we cannot change (Shared SAN, storage admins decisions, etc) we can live with that. Those that are really important are our database and transaction log initial file size and auto growth settings. If we don't set them correctly and/or leave them by default we risk to end up with huge disk and file fragmentation and hurt IO Performance. (see my previous blogs addressing fragmentation)

Most popular and highest rated presentations were those where I shared my experience. The “Top 10 thinks you shouldn't do”" session was enjoyable. There were so many people wanted to attend the session that some of them were sitting on the floor. I really hope I haven't disappointed them (Well, according to the feedbacks... I haven't so much:). I was really happy when I received a feedback the day after the session from a customer’s DBA. She said: “After your session I checked out & fixed the settings in our SQL Servers”. That is one of the best feedback I’ve received, because it makes me feel like my session helped someone not just having a good time, but doing the job better. I am really excited about how my “Top 10 thinks “ session  series go. I have so much ideas about it, at least I have almost structured my next Top 10 :) Responding to the request for ppt slides – see the link at the end.

SQL Server Unplugged session was the one I think I did best, it was so funny, I really enjoyed the time. I got some tricky questions, some funny questions and ..a  bunch of flowers at the end (many thanks to the HP people from the SQL User Group, you made my day :) Actually the session was one of the highest rated during the whole event. It was so nice to get this feedback, it was definitely energizing, something that keeps me going! I am really happy that the idea behind SQL Server Unplugged session worked out and was accepted by the audience. I will definitely continue to deliver and improve it. I will follow up some questions from the session in my next posts (one step at a time, by the way I am on a vacation right now, what a great time for blog postings, everyone is watching me in the SPA center while I am writing on my laptop:) Thanks God I got an IT husband)

I will not comment as much the R2 session because I feel it is not my best one. The jet lag, the fairy of the demos, almost everything was against me during that one hour :) But I hope my audience forgave me, taking the main point I wanted to give them - the feeling of what is coming, what to expect as a trends, not just showing some cool features.

My slides from MS Days 2010:

http://cid-7fb6c71238ff60f7.skydrive.live.com/browse.aspx/.Public/MSDays2010

Last but not least it is so enjoying to meet people not part of the usual technical community you you work with. Mary-Jo Foley is one of those impressive persons that can energize you from the very first contact. She will get you out from your comfort zone trying to hear beyond your words. It is a challenge and a great pleasure to talk with her. As one of my colleagues said: “Mary-Jo is an Institution, one of the last remaining truly IT journalists. Her book “Microsoft 2.0” is a must-read (and must-not-agree-with :))”

I am so proud to present you the result of my contact with Mary-Jo:

Margarita Naumova: Microsoft Women Worth Watching

http://blogs.zdnet.com/microsoft/?p=5799&tag=trunk;content

It is so nice, thank you Mary-Jo!