Excellent and informative post Michael, thank you! I, too, am nda on this but know it was well named. Kodiak was indeed a bear. Unbearably so, even.
It's not for nothing that ESE (Jet Blue) is irreverently and somewhat lovingly referred to by the product team as a drive-by database (no offense intended). It does what it does *extremely* well, and the products building upon it beyond AD & Exchange is growing - RMS, Sharepoint (duh), Certificate Services, ADFS, many others. >From our perspective it's a win-win. For once the competition between the product teams is healthy and we benefit. It's undeniable that the SQL team would like more than to eliminate that annoying ESE thing while the reasons so well stated here - and the valuable exercise that Kodiak was - continue to confirm that that won't happen any time soon. Good for both sets of products, good for us! :-) On Thu, Apr 26, 2012 at 7:01 PM, Michael B. Smith <mich...@smithcons.com>wrote: > I'm somewhat limited in what I can say, because what isn't public is still > under NDA, even though the project was canned. > > I can tell you this - there are some things that ESE does really really > well that SQL is very bad at. One of these is "instant" index generation. > Every mailbox comes with 10 views - each view represents a logical > association to an index for a table. Indices are maintained in last-used > order. So if you create a new view, the oldest index is deleted. As you may > or may not be aware - views are extremely customizable. And every user can > have different views. > > ESE is also VERY efficient at handling blobs. > > ESE does deadlock detection and lock arrogation very differently than SQL > does and based on the usage of an Exchange database (that is, the COMMON > case is that only one user is accessing a mailbox at a time) it is more > efficient. I challenge you to tell me the last time you saw > Outlook/Exchange report a deadlock (and there is such an error). > > All of these things are common knowledge. > > Another challenge is that the Exchange database schema is considered > proprietary. Note: I am not referring to the Active Directory Schema that > defines attributes, classes, etc. etc.; but the actually implementation at > the database level. Tables, rows, and indices. In SQL, the database schema > is easily discovered (and as a corollary, that capability is directly built > into the "tooling" that you refer to). In ESE, while the schema is part of > the database, it's stored at a much lower level than it is in SQL. For > example, in SQL you may declare "nvarchar(255) MessageId". In ESE, you can > create it that way, but the way it is stored in the schema is > "<column-number>, UTF-8 string, maximum length 255". No variable name. SQL > (as I understand it) doesn't have a mechanism for hiding the database > schema. > > That would make writing a SQL parser/interface for ESE quite challenging. > Not that it couldn't be done... at least for queries. Mapping updates and > creates to "standard SQL" would be quite challenging and would likely > require some changes (just like WQL does). > > And finally: > http://theessentialexchange.com/blogs/michael/archive/2008/04/16/Exchange-Server-SQL-Backend.aspx > > -----Original Message----- > From: Jason Gurtz [mailto:jasongu...@npumail.com] > Sent: Thursday, April 26, 2012 4:38 PM > To: MS-Exchange Admin Issues > Subject: RE: OT, sorta: New blog post: Determining the Exchange Version - > without using Get-ExchangeServer > > Ahh yes, I remember those rumors well (and being stoked about it). At the > time I had escaped the responsibilities of personally dealing with Exchange > 5.5 and thought a genuine sql interface would allow for the sorts of things > we were doing with sendmail and friends at $lastJob. Exchange might start > to get interesting I thought; alas... > > So here's a wish which hopefully doesn't come off too much like a whine: > > The wealth of tooling in the SQL Server product arguably exceeds that of > Exchange by a fair margin. Maybe someday there will be a mapi bridge to the > land of SQL Management Studio (hoping and wishing). With immediately > available value in things like Integration Services, Analysis Services, and > Reporting Services it's hard to think they're not still thinking about it > in Redmond...somewhere. > > Many riches granted the person who builds such a tool! > > ~JasonG > > > -----Original Message----- > > From: Michael B. Smith [mailto:mich...@smithcons.com] > > Sent: Thursday, April 26, 2012 09:05 > > To: MS-Exchange Admin Issues > > Subject: RE: OT, sorta: New blog post: Determining the Exchange > > Version > - > > without using Get-ExchangeServer > > > > Code-name Kodiak. > > > > It was Exchange-on-SQL. (SQL Server Yukon, what became SQL 2005.) It > ran, > > but it was a dog; even on 64-bit systems. > > > > There were learnings from that, both on the SQL side and on the > > Exchange side, but the decision was made to stick with ESE. And ESE > > has actually exploded in use in various places in Windows since then. > > Probably a couple of dozen features/roles that use ESE now. It's a > > major DB engine/platform - built into every Windows OS since Windows > > 2000 - that no one knows about. :-) > > > > -----Original Message----- > > From: Jason Gurtz [mailto:jasongu...@npumail.com] > > Sent: Thursday, April 26, 2012 8:49 AM > > To: MS-Exchange Admin Issues > > Subject: RE: OT, sorta: New blog post: Determining the Exchange > > Version > - > > without using Get-ExchangeServer > > > > Quite nice Michael, thank you for continuing to post these scripts. > > > > This reminds me, what ever happened to Exchange v7 (2003 being 6.5, > > 2007 being 8). > > > > ~JasonG > > > > > -----Original Message----- > > > From: Michael B. Smith [mailto:mich...@smithcons.com] > > > Sent: Wednesday, April 25, 2012 17:16 > > > To: MS-Exchange Admin Issues > > > Subject: OT, sorta: New blog post: Determining the Exchange Version > > > - without using Get-ExchangeServer > > > > > > New blog post: Determining the Exchange Version - without using Get- > > > ExchangeServer > > > > > > > > > http://theessentialexchange.com/blogs/michael/archive/2012/04/25/determin > > > ing-the-exchange-version-without-using-get-exchangeserver.aspx > > > > > > http://bit.ly/I24DiE > > > > > > > > > > > > Regards, > > > > > > > > > > > > Michael B. Smith > > > > > > Consultant and Exchange MVP > > > > > > http://theessentialexchange.com/ <http://theessentialexchange.com/> > > > > > > > > > > > > --- > > > To manage subscriptions click here: http://lyris.sunbelt- > > > software.com/read/my_forums/ or send an email to > > > listmana...@lyris.sunbeltsoftware.com > > > with the body: unsubscribe exchangelist > > > > > > --- > > To manage subscriptions click here: http://lyris.sunbelt- > > software.com/read/my_forums/ or send an email to > > listmana...@lyris.sunbeltsoftware.com > > with the body: unsubscribe exchangelist > > > > > > --- > > To manage subscriptions click here: http://lyris.sunbelt- > > software.com/read/my_forums/ or send an email to > > listmana...@lyris.sunbeltsoftware.com > > with the body: unsubscribe exchangelist > > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe exchangelist > > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe exchangelist > > --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe exchangelist
