Redbrick

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BE09.CB5A21A0 Content-Type: text/plain Forgive me if this is not the place to ask the question. My company wants to evaluate using RedBrick. Does anyone know if you can use a 4GL program with RedBrick ? If any one can help, please list the main benefits of using RedBrick as suposed to Informix version 9. Thanks Peter ********************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** ------_=_NextPart_001_01C2BE09.CB5A21A0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.2653.12"> <TITLE>Redbrick</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2 FACE=3D"Arial">Forgive me if this is not the place to ask= the question. My company wants to evaluate using RedBrick. Does anyone kno= w if you can use a 4GL program with RedBrick ? If any one can help, please = list the main benefits of using RedBrick as suposed to Informix version 9.<= /FONT></P> <P><FONT SIZE=3D2 FACE=3D"Arial">Thanks Peter</FONT> </P> <CODE><FONT SIZE=3D3><BR> <BR> *********************************************************************<BR> This email and any files transmitted with it are confidential and<BR> intended solely for the use of the individual or entity to whom they<BR> are addressed. If you have received this email in error please notify<BR> the system manager.<BR> <BR> **********************************************************************<BR> </FONT></CODE> </BODY> </HTML> ------_=_NextPart_001_01C2BE09.CB5A21A0--

Please don't post HTML. You can't use 4GL with Redbrick, I'm not sure about whether one of the 4GL clones supports ODBC, but I'd guess that a lot of stuff just wouldn't work. You can't really compare IDS 9, a general-purpose extensible database with RedBrick, a single-purpose reporting server. RedBrick is very good at running queries fast and loading big chunks of data, it's useless at everything else. -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule" - Coluche >From: "Loo, Peter" <Peter.Loo@capita.co.uk> >To: ids@iiug.org >Subject: Redbrick [21] Date: Fri, 17 Jan 2003 04:22:43 -0500 (EST) > >This message is in MIME format. Since your mail reader does not understand >this format, some or all of this message may not be legible. >Forgive me if this is not the place to ask the question. My company wants >to >evaluate using RedBrick. Does anyone know if you can use a 4GL program with >RedBrick ? If any one can help, please list the main benefits of using >RedBrick as suposed to Informix version 9. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

----- Original Message ----- To: malcolmw@fast24.co.uk At: 3/26 8:29 Several commercial applications, notably SAP and PeopleSoft, have 10,000-30,000 tables, that's the main reason. Also there are instances, like our development servers here, where you may have over 100 databases with a few dozen to a hundred tables each yielding thousands of DD entries. Art S. Kagel ----- Original Message ----- From: Malcolm Weallans <malcolmw@fast24.co.uk> At: 3/26 5:51 > Hello, > I am very interested in this question as at the moment I am working on a > problem in this area. Our problem is that we have evidence from onstat of > data dictionary thrashing on one node of a large network of > machines. The other nodes appear to be OK. On investigation of the > failing node we discovered that the dictionary cache was thrashing due to > the fact that there are 4 copies of the database on this node but this is > the only node with 4 copies. We have increased the number of > caches(DD_HASHSIZE) to 31 and the size(DD_HASMAX) to 32 and reduced the > amount of swapping going on. > My query is why would anybody set large numbers for DD_HASHSIZE and or > DD_HASHMAX? We have about 80 tables per Database. Even allowing for about > 30 system tables that still only gets to 110. We are nowhere near the 8000 > figure talked of elsewhere. Or have I missed something? > > regards > > Malcolm > > At 06:14 PM 25-03-03 +0100, Michael Mueller wrote: > >Hi, > > > >The reason why I "believe" this is that I have been working for Informix > > in the support area for more than 10 years and know the source code > >of the server quite well. I also have been working on some bugs in this > >area. > > > >DD_HASHSIZE configures the size of a hash list which looks like this: > > > > list[0] -> e -> e -> e-> e -> e > > list[1] -> e -> e -> > > ... > > list[DD_HASHSIZE-1] -> e -> e -> e-> e > > > >Every e is an entry containing a table name + a pointer to the table > >data (This is what onstat -g dic shows). A table is added to the cache > >by computing its hash value n. The table then goes into list[n]. This > >computation is done by adding all the character codes of the table name > >and by taking the sum modulo DD_HASHSIZE. The critical point about the > >hash list is that the chains shouldn't get too long and that entries are > >distributed more or less evenly. > > > >It seems that some people believe that this can be achieved in a better > >way if DD_HASHSIZE is a prime number. But I don't think this is true. > >(You could play around with different values of DD_HASHSIZE and look at > >the hash list using onstat -g dic.) > > > >If you still have contact to people who told you this I would be > >interested in what their arguments are. > > > >Michael > > > >ART KAGEL, BLOOMBERG/ 65E 55TH wrote: > > >>From the Informix Administrator's Reference P 1-35: > > > > > > DD_HASHSIZE ....> > > > > > range of values Any positive prime number > > > > > > Belief has nothing to do with it. BTW, when this was undocumented it > > was I who > > > spoke to the developers to determine the appropriate range of values before > > > publishing the parameter in my article for TechNotes (Vol 8, no 3). So, > > I know > > > of what I speak. > > > > > > Art S. Kagel > > > > > > ----- Original Message ----- > > > From: Michael Mueller <michael.mueller@kay-mueller.de> > > > At: 3/25 3:53 > > > > > > > > >>Hi, > > >> > > >>I know that Informix made people believe that cache parameters like > > >>DD_HASHSIZE must be a prime number. But I seen no reason for this. I > > >>even doubt that it makes any difference. The last thing I would expect > > >>is a crash if it is not. If a bug is sensitive to this parameter, my > > >>only conclusion is that it is probably related to the cache mechanism. > > >>Maybe it goes away if the cache is made so big that nothing is ever > > >>thrown out of the cache. > > >> > > >>Michael > > >> > > >>Art S. Kagel wrote: > > >> > > >>>On Fri, 21 Mar 2003 11:38:46 -0500, Rudy wrote: > > >>> > > >>> > > >>> > > >>>>Guys, > > >>>> > > >>>>I'm going nuts over this one... > > >>>> > > >>>>For the past few months, a specific development instance (out of our 40 > > >>>>odd) has been crashing periodically. Informix Tech support has suggested > > >>>>that its something to do with the DD_HASHMAX & DD_HASHSIZE parameters > > >>>>... and they are probably right because the problem has reduced after > > >>>>fiddling with them. However, the problem has not gone away. Besides, I'm > > >>> > > >>><SNIP> > > >>> > > >>>Yes, the problem is likely the DD_HASHSIZE which MUST BE A PRIME NUMBER! > > >>>None of the values below (8001, 8003) is prime except 4001! Try 8009 if > > >>>you want a value about double the 4001 number. Were you having problems > > >>>when it was 4001 or only since trying to change it? > > >>> > > >>> > > >>> > > >>>># DD_HASHSIZE 4001 > > >>>># rudy Mon Mar 17 16:33:21 EST 2003. Further changes (attempt both prime > > >>>>numbers) > > >>>># DD_HASHSIZE 8001 > > >>>># DD_HASHMAX 257 > > >>>>DD_HASHSIZE 8003 > > >>>>DD_HASHMAX 20> > >>> > > >>> > > >>>Art S. Kagel > > >>> > > >> > > > > > > > > > > > > > > >-- > > > >=== Michael Mueller ================== > >Tel. + 49 8171 63600 > >Fax. + 49 8171 63615 > >Web: http://www.mm.kay-mueller.de > > http://www.planets.kay-mueller.de > >====================================== > > > >