Today, as we write application code
we generally are not dealing with immutable state/data, we are applying application logic to state/data so that it transforms from one known state to another known state in a consistent, all or nothing fashion. Today, when performing this in code that does not involve Transaction Managers or Resource Managers, we use Try/Catch exception handling statements to mimick the "Commit" and "Rollback" concepts of transactions. The difficulties with such an approach is that as we scope certain types of work and/or scope more than a few simple actions into a unit of work, the level of complexity in nested try/catch code grows and can easy reach a point where it cannot truely provide the "Commit" and "Rollback" concepts of a Transaction.
For example,
take the Try/Catch below
try
{
// operation(stateX)
// operation(stateY)
// operation(stateZ)
}
catch
{
// cleanup after states X, Y, and/or Z, as something has gone wrong and we need to get to a previously known state
}
The challenges with using try/catch in a Commit/Rollback style are some of the following:
-
If stateX is shared between between more that one execution contexts, another execution context may read an inconsistent state and hence a "dirty" read, as the scoped unit of work may fail
- What if an operation on stateY deletes/alters a resource and how do we "Rollback" in the catch.
- How do we coordinate with resources that are transactional, i.e. if stateX represents a call to a transaction queuing/messaging or database system. How we coodinate between the different resources and unit of works!
- and there is lots of other problems
While all of the above can be eventually handled in code, with careful planning and structure, but what is the essence of what we are trying to achieve in the code and does it form a pattern! It is the "Commit" and "Rollback" concepts of a Transaction and if we factor the patterns, interfaces, contracts and interactions of Transacional Processing into the code we have more flexibility and agility. Please note I am not suggesting that every try/catch has a "Commit" or "Rollback" focus, but we sometimes use try/catch to group actions into a unit of work in which we determine the outcome of a unit of work by interrogation (using if statements) and do not negotiate/coordinate the outcome of the unit of work (as an example). Also, to provide the most flexibility and agility, we need for the actions that are grouped into a unit of work to be able to be aware of the (transactional) context. We also have the problem that try/catch is not context aware, i.e. it only knows a single execution context, and while dealing with a single execution context may suit us some times, we need to be able to handle both concurrency management and recovery control at the same time!
One approach to providing a cleaner implementation, is to factor out the interrogation and make it the negotiation/coordination of the outcome from the application logic and for an intermediary to work as a coordinator between the resources being used and the application logic. The coordinator controls the enlistment of resources within a scoped execution context (as defined by the application code) that we want to be transactional. We then need to define a number of common interfaces and interaction semantics, so that the use/enlistment of one or more resources in the scope/context of a unit of work is clearly defined. This can be achieved by having methods/semantics/behaviors common to all resources so that the different stages of moving/transforming from one known state to another known state as a unit of work or as a part of a unit of work, happens in an all or nothing fashion.
All of this fits quite nicely with the 2 phase commit (and even the one phase commit) protocol as to how the "Commit" or "Rollback" semantics of units of work can be achieved.
Oppps ....... Hmmmm ..... since I thought I was going to be able to do this is 3 to 4 postings, I seem to have underestimated and need one or two more. I think I will leave it here for now with this posting and follow up with a part 4,5,6
![]()
In general, when we think of Transactions we tend to think of database transactions. Databases are a great example of how a data server can implement transactions and therefore handle concurrency, provide isolation and provide consistency. The concept of what constitutes a Transaction expands beyond that of a Database Transaction and with this we have more and more areas where the abstraction and contracts that make up a Transaction can help us with the problem of how to handle concurrency management and recovery, as we apply application logic to state and consistently move from one known state to another.
So when we look at a Transaction, what are main parts involved? At a base level it is composed of three parties, i.e. an Application, a resource manager and a transaction manager. So how they are involved in a transaction and what is their role in a transaction?
The Application is pretty self explanatory, it’s your code. Its role in a transaction is to define the scope of a transaction, perform read/write operations on a resource manger and specify whether it views the state as being consistent. A resource manager is a component that manages a stable data storage system (i.e. it always shows a consistent view of data/state), and participates in the two phase commit and recovery protocols with the transaction manager. A transaction manager tracks which resource managers participate in the transaction, provides an interface to the application – start, commit, rollback and also, coordinates the transaction outcome between the resource managers. The transaction manager has the responsibility of properly handling error conditions, on behalf of an application, recover from them and ensure that the resource managers are always in a consistent state.
With today’s technologies the Resource Managers that typically get used are those of databases systems and queue managers. But is there other times when you need to be transforming/moving from one state to another? There certainly are!
The basic premise of Transactions is the coordination/negotation of an outcome that groups actions into a unit of work that transforms from one known state to another. As the transformation of state, the coordination/negotation of an outcome, or the grouping of action into a unit of work are something we do very often in application logic, is this not a Transaction.
So when do we get involved in the transformation of state, the coordination/negotation of an outcome, or the grouping of action(s) into a unit of work? What are we trying to achieve, how do we generally do it today and is there a better way to do it?
I've kicked off Part 3, to share my views on this and hopefully provide some insight!
![]()
When thinking about Transactions, I think it is fair to say that Transactions are one of the most powerful and frequently used paradigms in Enterprise Computing today. With Transactions, we have a collection of patterns that deal with how concurrency management and recovery control can be handled in possible shared/concurrent environments/contexts and it is this that ensures data/state correctness. It is the key concepts and abstractions of Transactions maintaining data/state consistency in possible concurrent state/data access environments (where failures may occur) that have allowed us as developers and architects to be largely released from having to deal with the tricky aspect of maintaining the correctness of state in concurrent environments in an enterprise application.
Two of the very interesting aspects of Transactions is how trusted they have become and how we perceive them. Concurrency Management and recovery control are some of the more tricky aspects of Enterprise Computing, but yet when leveraging the Transactional paradigm and executing units of work in a concurrent environment in the context of a transaction, we are not overly concerned about isolation or failure as much of the work is done for us by the Transaction Paradigm. This is a testament to the level of trust and adoption that Transactions have achieved as an abstraction and how it has evolved into a framework of runtime services that takes most of the responsibility for concurrency management and recovery control from us as developers and architects. The paradigm of Transactions can be seen as a set of patterns, Interfaces and Contracts that can be leveraged to simplify the transformation from one known state to another and without these Interfaces and Contracts; a lot of code, time and effort has to be spend in making sure that data/state transformations happen in a consistent and all or nothing fashion.
It is these key abstractions in the form of runtime services or frameworks that have provided great productive gains for us as developers and architects, as it allows us to focus on business logic and allows for the underlying runtime services to deal with concurrency management and recovery control. Therefore as we implement application logic, by applying units of work to state, we want the transformation from one state to another to be applied in a consistent (all or nothing) fashion, as well as wanting to be isolated from other parallel activities. As I mentioned in my
How should we think of Transactions ?
blog posting, I like to think of the Transaction paradigm as a collection of patterns, interfaces and contracts that can be leveraged to tackle the issue of data/state correctness as we group actions into unit of works to transform from one known state to another. Some of this collection of patterns, interfaces and contracts are short running transactions that in the main adhere to the ACID properties but there is a rich portfolio of transactional types that we do not focus on that much and/or maybe perceive as not meeting the ACID properties (see
How should we think of Transactions ?
and
Volatile Transactions & In-Memory Transactions - do they have ACID, ACId or ACI properties?
)
Today, the most common example of how the Transaction paradigm can provide concurrency management and recovery control is Database Management Systems (DBMS). Databases (aka DBMS) are themselves another key and often used architectural piece of Enterprise computing. Database Management Systems (DBMS) provide a paramount role in how an Enterprise may store, retrieve and share state/data. But we sometimes draw an association between Databases and Transactions that is so close that they are often perceived as being interchangeable, i.e. Transactions are DB Transactions and nothing else. The close associations between databases systems and transactional processing have been fundamental in bringing the concept of Transactional Processing to the fore, but in my honest opinion I think that the close association may have also brought a narrowing of perception of what are Transactions and Transactional Processing.
I have put together a series of blog postings to share my current views/thoughts! After talking to a few folks about Transactions, it is very interesting to hear the different views and I'm not sure if there is a one size fits all for what is a transaction, but this is the thing about a paradigm and a snappy acronym, it can have a life of its own
Maybe we interchange the paradigm, acronym’s and implementations into one fixed view and its this fixed view that maybe causing the issue!
![]()
In my last blog posting,
How should we think of Transactions ?
I mentioned Volatile transactions and how I currently think they can be perceived in different ways! Do they have ACID, ACId or ACI properties?
In case you do not know what Volatile Transactions (aka In-Memory Transactions) are, they are transactions that do not persist to a durable store such as a hard disk (ouch! we have multiple definitions of durable to content with
). They are transactions that are done completely in memory and do not incur the I/O cost of writing to a hard disk a Transaction log or the actual known data/state.
What is interesting about Volatile transactions is that they are sometimes perceived as not being Transactional, because they are viewed as not meeting the ACID properties, especially the "D" property. I suspect the main reason for this view is because there are no Transaction logs and/or no data stored to hard disk.
So when you look at a typical definition of the ACID properties (like what I have listed below), some of the reasons why this view maybe held become apparent:
(NB. this is an amalgamation/synopsis of many definitions I have seen)
A
- Atomicity - Transactions are atomic (all or nothing)
C
- Consistency - The transaction is a correct transformation of state. Consistency constraints that are defined on the underlying data servers are preserved by a transaction.
I
- Isolation - Each transaction should appear to execute independently of other transactions that may be executing concurrently in the same environment.
D
- Durability - Once a transaction commits, it’s updates survive even, if the system goes down
ok, so a Volatile Transaction meets the ACI of the ACID properties, but not the D as defined above. But is this ("Once a transaction commits, it’s updates survive even, if the system goes down") a true reflection of what Durability means? Many similar variants of this definition gets used on a frequent based and they bring specifics to the definiton that are not about the failure of meeting the ACI properties or making the "Commited" value available/public but focus on the failure of media or a system. In my opinion the failure of media or a system is not an aspect of the paradigm or indeed part of the ACID properties, but an aspect of how the paradigm can be implemented and/or a requirement of the longevity of the state being persisted/determined. It is perhaps the fact that the best known implementation of the data server feature of the transactional paradigm is a database that has led us to shape the ACID properties to the specifics of databases. But perhaps the Transactional paradigm has more to offer than the correctness of data/state transformations on a database. The transaction paradigm has a core focus on simpilifing how we can achieve the correctness of data/state transformations where we may have to deal with concurrency management and recovery control and this can be applied to any transformation of state.
Perhaps a different way to look at the durability of ACID is where the definition of ACID as an acronym came from and how some of the leading experts in the industry define them. As far as I know the ACID acronym was first coined by Haerder and Reuter (1983). The definition I like to use is that by Gray and Reuter (1993). It is the following:
A
- Atomicity - A transaction's changes to state are atomic: either all happens or none happen. These changes include database changes, messages, and all actions on transducers.
C
- Consistency - A transaction is a correct transformation of the state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.
I
- Isolation - Even though transactions execute concurrently, it appears to each transaction, T, that others executed either before T or after T, but not both
D
- Durability - Once a transaction completes successfully (commits), its changes to the state survive failures.
When you read this definition of Durability (and the ACID properties overall), it in my option explains the feature richness of transactions and how it can be applied to the persistence of the transformation of state and also how it applies to the other properties such as A, C and I. The state survives failures by the data server ensuring that when the transaction commits a new durable state is persisted/stable/available/public and if something goes wrong (such as not be able to ensure Consistency) that the data server returns to the previous known state. In essence, this is a contract that guarantees the persistence and stability of the state and that the outcome of a transaction is known/public and usable in subsequent transactions, as a known/correct state. A good definition I have seen is that once a transaction is committed, it cannot be abrogated.
With Durability being about the persistence, stability and making public of “commited”/known state as we transform from one known/correct state to another, it allows us to leverage the transaction paradigm in many scenarios. For example when using Volatile Transactions, we are leveraging data servers that store data on Volatile media, such as RAM and providing the transaction paradigm in-memory. With the common misunderstanding that Transactions are exclusively for databases, the question arises about the “D” property.
For me the Durability aspect of a transaction is present in a Volatile transaction. The question is whether its “D” or “d”. Since most transactions are based on the X/Open Transaction processing model, the requirement for log managers or lock managers in resource managers (data servers) are not central or core to implementing the transactional paradigm at a base level. In relation to the usage of Volatile media for Transactions? in my opinion the requirement of the media used by the data server is that it is able to present a stable/persistent/public state once "Commit" has occured.
So I believe that Volatile Transactions meet all of the ACID properties and that its ACID with a "D"
phew! long post.
I guess the crux of the issue is the 2 uses of "durable" when talking about Transactions. One is the "D" in the ACID properties and the other is the property of the data/state/media being used (and how it is stored). The "D" in the ACID properties is more about making a "commited" value available and the other is about an implementation requirement of how long (and/or resilient) a known/committed state must be.
![]()
This is an invitation given by Microsoft to leading edge application developers to participate in a research survey that seeks feedback on improving the application development experience working with data platforms. In the best interest of developers, the objectives of this survey are:
- To understand the existing, as well as upcoming challenges that has the potential of hindering optimal performance and productivity of those who develop applications and software components.
- To direct software manufacturers and its partners toward building powerful products that enable greater success among software development professionals.
- Determine the levels of priorities around improvements in data handling from the view point of developers.
This survey should take 10-15 minutes at the maximum. We encourage you to be as honest and candid with your feedback, and to reflect the current state of your experience today on the primary database and development tools you use.
Click here
to enter the survey site and see if you qualify for the profile of respondents we seek to complete this survey. Great prizes will be raffled off among the first 500 respondents who meet the target profile
and
complete the survey.
To forward this survey request to someone else,
click here
.
>
This weblog is sponsored by
SQLskills
.
![]()
From Jan till July of next year, the
Route64 Training Tour
is visiting over 20 cities providing:
-
Windows 64-bit Hands-On Training
is a 3-day training designed to provide the most comprehensive contents of of what it takes to fully leverage Windows on 64-bit processors. At the completion of this training, we expect attendees to be fully comfortable with developing on Windows 64-bit and in some cases to have fully ported their application. This training includes two tracks, the Server and Client Tracks. Read more about the tracks.
-
Windows 64-bit Compatibility Workshop
is a one-day training for ISVs and Enterprise developers who are looking at testing their 32-bit application on a Windows 64-bit. The workshop includes several hands-on sessions on three architectures to give you the opportunity to experiment with Windows 64-bit.
-
Windows 64-bit Device Driver Workshop
is a one-day training for IHVs and Enterprise developers who wants to start porting their 32-bit device driver on Windows 64-bit. This workshop is designed to present the key differences between a 32-bit environment and a 64-bit one. It includes several hands-on sessions on porting Device Drivers. Because of the complexity of running a Device Driver workshop, this workshop runs only in some selected cities.
So if you are looking to learn more about:
- Windows 64-bit & Hardware Architectures
- Migrating C/C++ Applications to Windows 64-bit
- Optimizing SQL Server on 64-bit
- OpenGL in a 64-bit environment
- COM Components in Windows 64-bit
- .NET Managed Code in Windows 64-bit
as well have opportunities on
three
different configuration of Windows 64-bit:
• Windows Server 2003 SP1 64-bit Edition on Itanium 2 processor
• Windows Server 2003 SP1 64-bit Edition on Xeon processor
• Windows XP 64-bit Edition on Xeon processor
You can find more details and how to register at the Route64 site (
http://www.route64.net/
)
![]()
Starting the week of December 6th
, Microsoft will launch a series of webcasts focused on SQL Server 2005 Development. During the week of December 6th, Microsoft/MSDN will host 15 webcasts introducing all the new features of SQL Server 2005 for Developers. Then,
starting in January
, there will be at least one webcast per week focused on specific developer topics for SQL Server 2005.
There are a bunch of benefits to watching this series (
in addition to the wealth of information provided
;):
- Everyone who attends a webcast will receive a copy of the Beta 2 Resource Kit and the Beta 3 Resource Kit when it ships.
- The first 1500 people that watch 5 or more webcasts will also receive a special, limited edition SQL Server 2005 Webcast T-shirt.
-
All webcast viewers will be entered into a competition to win an XBOX, one for each day of the week. The official rules are
here
.
The official site with session information, dates, times and abstracts is:
http://msdn.microsoft.com/SQL/2005Webcasts
and if I hear of any updates I will also keep you posted on further details, etc...
This weblog is sponsored by
SQLskills
.
![]()
The title is a common question I've received in the past and I thought I'd take a few minutes to explain a bit about keys and indexes...
This is by no means a lot of detail regarding relational theory, etc. but there are a few things that we should quickly review to make sure that the basis for indexes being created makes sense. First, from a relational theory perspective every table must have a primary key. From SQL Server's perspective it's not a requirement but it's generally a good idea. A primary/unique key are entity identifiers. Each are a unique way of identifying a row. There are subtle differences between the two - in implementation:
Primary Key
- In SQL Server the Primary Key is enforced through a Primary Key Constraint.
-
None
of the columns that make up the primary key allow nulls.
- The values in the Primary Key must be unique - to enforce uniqueness (as well as make it efficient), SQL Server creates a unique clustered [composite] index on the column(s) that make up the key.
Unique Key
- In SQL Server the Primary Key is enforced through a Unique Key Constraint.
- The columns that make up the unique key CAN allow nulls but not for more than one complete key. Meaning that allowing Nulls on a single column unique key really only allows NULL (only one NULL value). Overall, allowing Nulls in a column (like Social Security Number) doesn't really make much sense but if you need to then you can't go with a unique constraint - instead consider a unique index. At that point, I typically get the question of what's the difference between a unique key and a unique index...
- Allowing Nulls values in the columns that make up a composite unique key makes more sense as long as the complete key is not null for more than one row.
-
The values in the unique Key must be unique and to enforce uniqueness (as well as make it efficient), SQL Server creates a unique
NON
-clustered [composite] index on the column(s) that make up the key.
What's the difference between a unique index and a unique constraint?
- A unique key CAN be referenced by a foreign key constraint and a column which has only a unique index cannot be referenced.
-
Constraints are checked before indexes and this can lead to a large multi-row insert/select or update to fail before modification. However, indexes might (for a large modification) be validated at the end (instead of row by row) so a large modification that has a failure will need to rollback at the end of the modification rather than before. This is a good point - and one I hadn't really thought of until I was poking around some of the Q&A on SQLMag's website.
Here's where I found it.
So, all of this leads me up to the original question (
yes, you knew I get here someday
:) and that's
“When did SQL Server stop putting indexes on Foreign Key columns?”
First, SQL Server has
NEVER
put an index on a foreign key column... Indexes are used (as described above) to make the lookup (in a primary or unique key) for a duplicate value FAST. If the keys are ordered then checking to see if one already exists is trivial (i.e. fast). There is NO reason for SQL Server to put an index on a foreign key column as the column does not (and probably would never be) unique (if it is then it's likely to have a primary or unique key on it as well - as in a 1-1 relationship). So, that leads me to another key point...
Are there any benefits to indexing foreign key columns?
YES
-
Better performance on maintaining the relationship on a delete of a primary/unique key. When you delete a key row, SQL Server must check to see if there are any rows which reference the row being deleted.
-
If the foreign key relationship is defined with NO ACTION (on update/delete) then a referenc
ed
row
CANNOT
be deleted as it would leave the referenc
ing
rows “orphaned.” To find the rows efficiently an index on the foreign key column helps!
-
If the foreign key relationship is defined with CASCADE (on update/delete) then when a referenc
ed
row is modified all of the referenc
ing
rows must be modified as well (either updated to reflect the new value or on cascade delete). To find the rows to modify efficiently, an index on the foreign key column helps!
- Better join performance - for many of the reasons above, SQL Server can more effectively find the rows to join to when tables are joined on primary/foreign key relationships. However, this is NOT always the “best” indexing choice for joins but it is a good start.
Finally, if you want a few titles related to relational theory check out these links:
An Introduction to Database Systems, Eighth Edition
by C.J. Date
E.F. Codd
Database Design for Mere Mortals:
A Hands-On Guide to Relational Database Design
Mike Hernandez
Have fun!
kt
This weblog is sponsored by
SQLskills
.
![]()
During the week of October 11, I delivered a four day “immersion” event where we focused on nothing but performance tuning - from design to indexing to optimizing procedural code. There were many states represented (CA, CT, FL, GA, IL, IN, KY, MA, MI, MS, NE, NY, OH, OR, TX, UT, WA, and WI) and it led to some great conversations - even outside of SQL! For the attendees, we had long days with lots of content (the comprehensive agenda is
here
) and evenings in a great city (
yes, Chicago is my home town
). And - to end the four-day even and kick off Bill's Friday event, I just couldn't let a group of so many visitors leave Chicago without having Chicago Pizza. On Thursday night we hit Pizzeria Due:
Not everyone was able to make it for dinner but we did happen to get a nice group shot here:
Finally, a few of the attendees were able to play “tourist” for a few minutes (
I don't know how they had the energy!
) and here are a couple of pictures I want to share with everyone. These next two Chicago pictures were taken by Ken (
he's a New Yorker who was in town for the event - but we won't hold that against him
:) :) :). In the first image, Ken took nine images facing North from the John Hancock building and in the second photograph there are five images facing South from the Hancock. Both of these are the result of “stitching” the images back together. Very cool Ken - THANKS!
Facing North from the John Hancock Building:
Facing Sorth from the John Hancock Building:
A fun event, a great group and a wonderful way to kickoff of our SQL Immersion event.
on
SQLskills
if you'd like to hear more about our upcoming SQL Immersion events planned for 2005 as well as those planned on SQL Server 2005.
This weblog is sponsored by
SQLskills
.
![]()
Well, it's a small country - but with a huge population of SQL Server users - especially as far as ratios go! This week I've been in Reykjavik, Iceland delivering my second SQL Server Immersion Event on SQL Server Performance Tuning and Optimization which was hosted by my friends at
Miracle Iceland
.
fyi - I still have to post a few pics from my Chicago Immersion event and I hope to do that tonight as well!!!
Class is over and I just thought I'd say a final thanks to all the great people I met this week. I'd also like to mention how impressed I am wrt to the major load reduction against the
Miracle Mainframe (jpg 185.28 KB)
.
Thanks!
This weblog is sponsored by
SQLskills
.
![]()
In a few past posts, a couple of other friends/RDs have given me geeky sql titles... such as sql hera (which
Forte
started
here
, referenced
here
and resulted in ) and the original culprit (from
Clemens
) started it all
here
....... major harrassment ensued and my irritation was subdued solely by being worn down.
Anyway, after months of avoiding the titles, I have decided to give up the fight and take advantage of a couple of birthday presents. Yes, I now own a couple of new domains. If you can guess what they are then you can get to this blog faster... they solely redirect you to here.
I hope all is well!
This weblog is sponsored by
SQLskills
.
![]()
Wow, seems like forever since I last blogged... and yes, it was! Many exciting things have happened over the last few weeks and that's part of the reason for my silence... Thought I'd do a quick list of highlights and hopefully I'll expand on a few of these things over the next few days.
At the end of Sept - went to SQL PASS in Orlando which started a day late due to yet another hurricane but despite the lost day, once PASS got started it went really well. I did a lecture on Partitioning in addition to an all day workshop on “Designing for Performance.” One of the highlights of the conference for me (
since I was a judge
:) was the opening reception where we played a game show like game of trivia... It was quite a bit of fun deciding if the answer was “correct.” Turns out there are a few different things we all call SPIDs. The answer for the question was “server process ID“ but I allowed system process ID as that's what many of us call it... In fact, search through the books online for a couple of minutes and you'll see it called both. Well, I feel better now :). OK, enough of that. The “final question” was a good one though - what is the correct way to reduce the size of the transaction log. No one had the syntax right (but no one really tried either :) and the correct answer is...
(1) Clear space from the transaction log using BACKUP LOG.
The key thing that I want to stress here though is that “clearing” space from the log does NOT have to be done with the TRUNCATE_ONLY or NO_LOG operations... you can “clear” space from the transaction log by
(2) DBCC SHRINK
FILE
can then shrink the unused space from the transaction log - allowing you to shrink it down to a defined size (which is an option of shrinkfile) or you can shrink the transaction log down to the smallest possible size by using the TRUNCATEONLY option. One of the benefits of shrinking the log down to the smallest possible size would be to then alter the transaction log size by using ALTER DATABASE modify file to set the transaction log to the appropriate size. By shrinking and then altering in one step (altering to the necessary size based on transaction log activity and maintenancec requirements) you can reduce internal fragmentation in the transaction log.
OK, fragmentation in the transaction log is another story but as for the answer - BACKUP LOG and DBCC SHRINKFILE were accepted as the correct answer. If someone supplied only one part we didn't give any points (mostly because you wouldn't have really been able to shrink the log without both)!
After PASS I was back to Seattle to attend a beta course delivery of a new SQL Server 2005 course which is part of the SQL Ascend program. I've teamed up with
Scalability Experts
to deliver some of these workshops in 2005 and we're really looking forward to the events. This 5-day course is intense and covers a wide range of IT-related new features of SQL Server 2005. I'm looking forward to starting these deliveries in January!
After the course I was off to Chicago for our first ever SQLskills SQL Immersion event. It was GREAT! We had a blast!! The event hours were long but we got A LOT accomplished. Each day the room opened at 8am and a light breakfast was setup. Class officially started at 9 and we had lunch (and snacks) catered during the course. Each night a number of attendees stuck around for questions/playing/analyzing queries, etc. from 5-7pm and a few nights I didn't get out of there until almost 8pm. Yep, we work 1/2 days at SQLskills - any 12 hours you want! :) Each night we tried to attack as many real world problems as we could! As the week progressed, we solved quite a few interesting issues and the result for some was a gain in disk space (and quite a bit of it :) :), a gain in performance or for some - both! It was really fun to watch the -
real time
- practical application of many of our tips as the week progressed. I'm anxious to hear more from everyone as applications improve.
As for the content - it was all about Performance Tuning and Optimization from Design to Indexing to Optimizing Procedural Code. I delivered the first four days and then
William R. Vaughn
came in to deliver our client side lecture on Friday covering ADO.Net Best Practices in Data Access. Most of us went out for pizza on Thursday night (
I couldn't possibly have allowed a Chicago event to occur without everyone having world famous Chicago pizza - would have gone to Uno's if they could have supported the group size but we ended up at Due's... pizza was excellent
). As for why people weren't already familar with Chicago pizza... we had attendees from around the country - CA, CT, FL, GA, IL, IN, KY, MA, MI, MS, NE, NY, OH, OR, TX, UT, WA, and WI (a nice SELECT distinct state ORDER BY from my registration db ;). Everyone had great questions, excellent “problems/issues” to tackle and together it was a fantastic mix of backgrounds and personalities.
THANKS FOR A GREAT WEEK EVERYONE!
As for this week - I'm in Iceland and it's been colder than I had expected (
no, I'm not a complete idiot - thank you
)... They've had UNSEASONABLY cold weather and a crazy 3 day wind storm that's hit wind speeds of 134 mph. Most of the time they've just been 60-80mph but WOW it's been windy....especially at night. Today was quite nice and the weather is supposed to get better for the weekend (at least that's what the local weather folks have said... I'm definitely not going to believe weather.com right now ;). And - what am I doing here? I'm delivering another Immersion Event partnered with the local
Miracle
folks. It's my second time here and once again - the warmth of the people (
not to mention the plentiful beer
:) makes up for the colder temperatures! As for a local highlight, today I continued to aid in further load reduction of the Miracle mainframe... Huh? The Miracle mainframe currently holds 37 types of “Miracle dollars.” There's a bit of a story behind this but it relates to a previous form of payment that was made with beers... So yes, the Miracle mainframe has 37 types of beer and each night we partake in some load reduction to help out the mainframe! Still a few days to go...
From Iceland I head to Denmark to deliver a two hour lecture for PASS-Denmark and then next Thursday a few of us will be driving to Lalandia for the final
DBForum
event.
I head back to Redmond soon after DBForum ends and then there are only four more events this year:
7-10 November - Las Vegas, NV
15-19 November - Copenhagen, Denmark
22 November - Special 1-Day Indexing Event in Oslo, Norway
23-25 November - EastMed Developers Conference (EDC 2004) in Amman, Jordan
No links for the last two... *I* probably couldn't read them regardless. But - I will keep you posted.
After all the travel, I'll be enjoying as many consecutive weeks at home as I possibly can. Hope to see you soon!!!
This weblog is sponsored by
SQLskills
.
![]()
While getting ready for the
PASS Community Summit
in Orlando this week (where I plan to talk about SQL Server 2005 Partitioned Tables/Indexes), I realized we were close but not quite ready to release the post-beta II whitepaper on MSDN.
So, in preparation for PASS we decided to post a pre-release of the partitioning paper
here
.
Enjoy!
See you in Orlando... eventually?!
This weblog is sponsored by
SQLskills
.
![]()
Each year as the weeks approach my September trip to Florida, I hear about hurricane after hurricane. I always wonder why conferences choose September (
or August or October for that matter
) in Orlando?? However, having said that - I've been to Orlando in September for the last 3 years and the weather's always been perfect! OK - I've probably just jinxed it?!
If you're going to be there, make sure to stop by and say hi!
I'm
delivering a
pre-conf on Tuesday
and a
SQL Server 2005 session on Wednesday
as well as sitting in on the Women in Technology Luncheon on Friday. The luncheon's are quite fun too! I've now done a couple of these and we typically end up chatting about how we got into high tech and how we stay motivated (
which quite honestly, doesn't only apply to women!
).
I hope to see you there!
This weblog is sponsored by
SQLskills
.
![]()
|