Ah Brett, you incorrigible one, you misunderstand my point of posting those
numbers.... It wasn't to say, look how big I have seen, but instead, look
how big these companies are and they still have small DBs. When I hear of
some giant DB I don't think wow, what a big DB, I think, what kind of sh*t
is being thrown into that AD to bloat it to that extent[1]?  I especially
love hearing about companies that jam huge binaries into the directory like
images that get replicated to the four corners of the earth and are only
read by one program, a web app, in one or two of the company's datacenters.
Great use of bandwidth. I also especially love seeing a crap load of data
going into the directory for Exchange when Exchange is centralized, also
great use of bandwidth. That site in South America or in Kuala Lumpur with
10 people and a GC because they have crappy connectivity certainly needs to
have every object and the entire Exchange selection of data for the other
200,000 users. No possible issues in data theft there... 

I think after we get past the training of everyone to only grant permissions
to those that really need the permissions and just those specific
permissions to just those specific people, we will start training everyone
to only put the data where it is really needed. Anyone with a really large
DIT should sit down and look at what is in it and say, is it really
necessary for all of this data to go where it goes? Is there additional
exposure that I have for putting it there that isn't necessary? 

Brett, while we have your attention if we do... How about some training on
max data stored per object. What are the limits that we will hit as we stuff
more and more data into say every user object? I know I have found the magic
admin limit exceeded when punching a bunch of data into a non-linked
multivalue attribute and it causing me to not be able to add any new
attributes to the same user object. What other limits are we going to see?
Also, why do I see that admin limit on new attributes when the one single
multivalue attribute get filled up?

  joe


[1] I really am not an entirely negative person. I am best described as a
optimistic pessimist. Hope for the best of all worlds but plan for the
worst. I have also been called a Socialist because I am willing to buy a
burger for a friend and a good conversation. ;o)



 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
Sent: Sunday, October 09, 2005 11:29 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Adding custom fields to AD

Mylo, from the way you speak of JET, I suspect you might not know of the two
JETs, and be thinking that JET = Access ... make sure you're "edJETicated"
(man, I slay me! ;), see Notes at bottom of this:
 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese/por
tal.asp
This frequent confusion, is the reason we use the more desired term, ESE.  
The two JETs once compatible at the top level API, have not even had to
maintain API compatibility for nearly 10 years, so they are quite different.

If the _active amount of data_ (and the active amount of data, can be
grossly enlarged by bad queries) exceeds memory, some operations will
probably be thrown down to random disk IO speed (100 IOs / second is a
standard single spindle/disk) ... ergo you get slow quick.

And like most database servers in such a situation, you can often throw
hardware at it.  We have Exchange servers with a TB of databases attached,
and a much higher update rate, BUT a big SAN to satisfy the IO load.

With AD you have the added advantage of being able to throw RAM at the
situations, with a 64-bit native OS and 32 GBs of RAM, a 29 GB database
performs quite well.

So where AD caves in, is very hardware and workload dependant ... joe's
production numbers aren't even interesting anymore. (implying many customers
are in production with much bigger databases) ;-)

Cheers,
BrettSh [msft]
JET Blue, not JET Red Developer.


On Sat, 8 Oct 2005, Gil Kirkpatrick wrote:

> Much of AD's heritage lies in the old Exchange directory, which was 
> ESE-based.
> 
> -gil
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of joe
> Sent: Saturday, October 08, 2005 8:38 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Adding custom fields to AD
> 
> > One thing I am curious about though is why MS opted for JET as the 
> > DB of choice for AD.. was it the only viable option at the time ?
> 
> What do you feel is wrong with ESE (aka Jet Blue)?
> 
> 
> > What's the ceiling on actual database size before it caves in
> (performance-wise)? 
> 
> Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max 
> pages [1]). As for when it caves perf wise from an AD standpoint it 
> really depends on what you are doing with it and what you have indexed 
> from what I have seen. If someone is issuing crappy inefficient 
> queries it will seem to be pretty slow pretty fast with relatively 
> little data.
> 
> The largest DB I have seen in production has been ~20GB and that was 
> with W2K on a GC and a bunch of that data shouldn't have been in the 
> AD like duplicated ACEs and misc unneeded objects, etc. Going to K3 
> would probably reduce that DB to about 10-12GB or better due to single 
> instance store, cleanup would reduce it even further. One Fortune 5 
> company I have worked with had a K3 GC DB in the area of 5GB and that 
> was for some 250,000 users with Exchange and multiple custom 
> attributes.
> 
>   joe
> 
> [1] See the docs for JetCreateDatabase - 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/e
> se
> /jet
> createdatabase.asp?frame=true
> 
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mylo
> Sent: Friday, October 07, 2005 9:04 PM
> To: ActiveDir@mail.activedir.org
> Subject: Re: [ActiveDir] Adding custom fields to AD
> 
> That's a good point about plonking stuff in AD.... a case of once a 
> good thing comes along everyone wants to climb aboard. I remember 
> doing ZENworks stuff with Novell where all the application 
> configuration information for software distribution was shunted into 
> NDS/E-Directory... all that bloat adds up replication-wise (still, at 
> least there was partitioning).
> 
> One thing I am curious about though is why MS opted for JET  as the DB 
> of choice for AD.. was it the only viable option at the time ? What's 
> the ceiling on actual database size before it caves in 
> (performance-wise)?
> 
> Mylo
> 
> joe wrote:
> 
> >I am going to basically say what the other said only I am going to 
> >put it this way
> >
> >IF the data needs to be available at all locations or a majority of 
> >locations where your domain controllers are located, consider adding 
> >the data to AD.
> >
> >IF the data is going to be needed only at a couple of sites or a 
> >single
> 
> >site, put them into another store. My preference being AD/AM unless 
> >you
> 
> >need to do some complicated joins or queries of the data that LDAP 
> >doesn't support.
> >
> >There is also the possibility of using app partitions but if you were 
> >going to go that far, just use AD/AM.
> >
> >The thing I have about sticking this data into AD is that AD is 
> >becoming, in many companies, a dumping ground of all the crap that 
> >was in all the other directories in the company. I realize this was 
> >the initial view from MS on how this should work but I worked in a 
> >large company and thought that was silly even then.
> >
> >The number one most important thing for AD is to authenticate Windows
> users.
> >Every time you dump more crap into AD you are working towards 
> >impacting
> 
> >that capability or the capability to quickly restore or the ability 
> >to quickly add more DCs. The more I see the one stop everything 
> >loaded into ADs the more I think that the NOS directory should be NOS
only.
> >Plus, I wonder how long before we hit some interesting object size 
> >limits. I have asked for details from some MS folks a couple of times 
> >on the issues with admin limit exceeded errors that you get when 
> >overpopulating a normal multivalue attribute (i.e. not linked) and it 
> >causing no other attributes to be added to the object. I wonder what
> other
> limits like that exist.
> >
> >
> >
> >   joe
> > 
> >
> >-----Original Message-----
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff
> >Sent: Tuesday, August 09, 2005 12:16 PM
> >To: ActiveDir@mail.activedir.org
> >Subject: [ActiveDir] Adding custom fields to AD
> >
> >Group,
> >
> >My manager wanted me to check, even though, I don't think that it is 
> >possible, but, I will present the question.
> >
> >He would like to add some custom fields, about 30, to AD.  He would 
> >like to add bio information into AD to be pulled by Sharepoint and 
> >other applications for people to read. I think that this is a waste 
> >of time, space and effort.  However, it is not my call and if this is 
> >what
> he
> wants....
> >
> >What are everyone's thoughts on the topic?
> >
> >Thanks
> >S
> >List info   : http://www.activedir.org/List.aspx
> >List FAQ    : http://www.activedir.org/ListFAQ.aspx
> >List archive: 
> >http://www.mail-archive.com/activedir%40mail.activedir.org/
> >
> >List info   : http://www.activedir.org/List.aspx
> >List FAQ    : http://www.activedir.org/ListFAQ.aspx
> >List archive: 
> >http://www.mail-archive.com/activedir%40mail.activedir.org/
> >
> >
> >  
> >
> 
> List info   : http://www.activedir.org/List.aspx
> List FAQ    : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
> 
> List info   : http://www.activedir.org/List.aspx
> List FAQ    : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
> List info   : http://www.activedir.org/List.aspx
> List FAQ    : http://www.activedir.org/ListFAQ.aspx
> List archive: 
> http://www.mail-archive.com/activedir%40mail.activedir.org/
> 

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to