I say "we" because I am one of the developers who has worked on the engine for the last 15 years (around half of it's existence).
Since I have worked on the engine, it has had a limit of slightly less than 2^31 database pages, which since it has a variable page size, has historically been 4 to 64 TBs.
Even before the 2nd rewrite in the 90s, I believe it had a 16 GB limit, so I really think the 2 GB is JET Red.
Brett Shirley [MSFT]
It should be noted that local SQL Server using fast IPC communication is quite good and rumors of Microsoft Exchange replacing ESE with SQL Server have popped up many times over the years.
From the ESE wiki page:
> For JET Red storage engine of Microsoft Access, see Microsoft Jet Database Engine.
> Extensible Storage Engine (ESE), also known as JET Blue, is an ISAM (indexed sequential access method) data storage technology from Microsoft. ESE is the core of Microsoft Exchange Server, Active Directory, and Windows Search. It's also used by a number of Windows components including Windows Update client and Help and Support Center. Its purpose is to allow applications to store and retrieve data via indexed and sequential access.
> ESE provides transacted data update and retrieval. A crash recovery mechanism is provided so that data consistency is maintained even in the event of a system crash. Transactions in ESE are highly concurrent making ESE suitable for server applications. ESE caches data intelligently to ensure high performance access to data. In addition, ESE is lightweight making it suitable for auxiliary applications.
> The ESE Runtime (ESENT.DLL) has shipped in every Windows release since Windows 2000 [...]
I was wondering how that might fare with the SQL Server edition meant to be bundled with apps. Besides being non-SQL seems it could be lighter keeping transactions and concurrency.
Looks a bit like Microsoft's c++ toolkit that serves a similar use as lmdb, I guess? (although jet seems to do more than "just" db).
In the server cloud business all the events streams (and we have several) are rolled up into optics web reports and analyzed and sifted for potential emergent issues and health metrics ... in this case, an event useful to our cloud server business leaked into the events of our Windows client business. This is (in my biased opinion;) less about being "server grade", and more about not being "properly embeddable" ... as generally embedded components should be quiet.
This is part of the challenge of making a DB engine that services two very divergent scenarios. This is the smallest of those challenges. How much memory we can allocate being the largest regular conflict ... Office 365 would not even notice if ESE allocated an extra 1 MB per process, but that would boost our Working Set numbers by 40% (from the last numbers I remember seeing) for each Windows Client Service using us.
Anyways, I have fixed the code to not log that event on Windows Client. It should clear up once that patch gets out.
Cheers, Brett Shirley [MSFT]
P.S. - Oh and I am sorry if it caused you any stress. I know it sounds concerning, but it is truly innocuous. You can ignore it, and hopefully soon you won't see it.
I guess that's a question: what would it look like on a Windows 10 system if it had a truly broken ESENT installation? As far as I know ESENT has never directly been a problem. Its log output is just part of the noise that now makes using the Event Viewer a complete waste of time unless one knows precisely when a problem was logged.
> Feel free to reply here with your flame. ;-) I can handle it. Really. :)
Believe me, if I thought the state of the Event Viewer and its logs were the fault of any one person, I'd be able to muster some sort of impassioned, vituperative response. I'm not angry, son, I'm just so disappointed in you. Ahem.
I saw this used as the "we really need to plug this performance hole" caching solution on a web server.
Without knowing too much about how well it did, I have to assume it does especially well in combination with IIS?
Would be interesting to find out how tightly coupled these benefits, if any, are.
-- Me : 2012 Source: http://mikewarot.blogspot.com/2012/01/
This repo in particular sure shows its age, because just clicking around, this code is totally nonsensical to me, haha. I couldn't even make a guess as to what it's doing.
https://github.com/microsoft/Extensible-Storage-Engine/blob/...
Brett Shirley [MSFT] (yes, the Brett Shirley contributor to the project ;-)
BOOL fVisible;
INT cbKey = 0;
BOOKMARK bmSearch;
ULONG cbReq;
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Neat that it is still around. A shining example of code being eternal!
But they plan to re-release with "cleaned up" comments. It will be way more interesting then, and with no ambiguity about its free software compatibility status.
Edit: to be clear I'm not really complaining, it is more that I'm eager to see the real thing, and also wanted to remind people what "source code" is by the definition of an important licence for free software. Here this is specified as "MIT License", which is often considered compatible with GNU GPL v2 or v3: but be warry that it is doubtful this is compatible with the GPL in this state, you'll have to wait a little if you want to do an integration in this direction.
This is a whole lot better than nothing.
This sounds weird, wonder what they're worried about here: Personal Information? Profanity? Or just airing their dirty washing in public.