IDS or SE and more questions

Hi, first my thanks to all who helped me with the first encounter of the INFORMIXSERVER variable. After I had at least the brilliant idea of starting an instance of sqlexecd everything ran fine ;-) So switching from SE 5.0 to SE 7.24 seems no problem for our application. When I finished the first test my boss had the idea of accessing multiple databases simultaneously. Flipping through the answers showed up that SE does not allow distributed databases. The online version will probably too expensive for us so I want to check out the IDS workgroup edition. While digging my way through the documentation (thanks for informix putting this online) I would like to hear the opinions of some long time experts or users of IDS. Our applications feeds around 50 users, database size is approx. 200 MB. The hardware platform will be a Sun Ultra 60 with 2 processors, 1 GB RAM and eventually an external Raid system (the previous system is a 5 year old Sun 20 with 300 MB so the new hardware should give our application an additional boost ;-) I'm just my way through the "Getting started" manual and have the following questions (until now): 1. If we use multiple separate databases on the system using the same connection type (setlitcp): would it be better to add a service and a sqlexecd for every database or is sufficient to have just one service for each different connection type? 2. Can the sqlexecd check if it's already running a service or will I run into trouble if the sqlexecd is acciedently started twice with the same arguments? 3. IDS can use raw disk space. Will this be noticably faster than using the unix filesystem (I would think so, but will it be only 20% or doubling/tripling the speed)? 4. IDS can use disk mirroring. Instead of adding a raid system would it be more usefull adding a 2nd disk controller and just double the number of disks (1 disk for temporary files, 1 disk databases and this doubled)? 5. Is the 'archive' backup program part of the IDS or is this a separate product? The "Getting Started" does not answer this. Is there anything obviously I'm missing on planning this? TIA for all your answers Axel (sunday and time for the Admin Guide - only 1200 pages to go)

Axel Sander wrote: > > Hi, > first my thanks to all who helped me with the first encounter of the > INFORMIXSERVER variable. After I had at least the brilliant idea of > starting an instance of sqlexecd everything ran fine ;-) > > So switching from SE 5.0 to SE 7.24 seems no problem for our > application. When I finished the first test my boss had the idea of > accessing multiple databases simultaneously. Flipping through the > answers showed up that SE does not allow distributed databases. The > online version will probably too expensive for us so I want to check > out the IDS workgroup edition. While digging my way through the > documentation (thanks for informix putting this online) I would like > to hear the opinions of some long time experts or users of IDS. > > Our applications feeds around 50 users, database size is approx. 200 > MB. The hardware platform will be a Sun Ultra 60 with 2 processors, 1 > GB RAM and eventually an external Raid system (the previous system is > a 5 year old Sun 20 with 300 MB so the new hardware should give our > application an additional boost ;-) > I'm just my way through the "Getting started" manual and have the > following questions (until now): > 1. If we use multiple separate databases on the system using the same > connection type (setlitcp): would it be better to add a service and a > sqlexecd for every database or is sufficient to have just one service > for each different connection type? If you're using IDS, you will be using oltlitcp, not setlitcp. You will most probably set up a single IDS instance to run all the various databases -- assuming they all have a different name. If you use a single database name and multiple locations with SE, then we have a bigger re-engineering problem. Given that you are using IDS too, then you won't be running sqlexecd; the oninit process handles the connections for you (CPU VP or NET VP). So, with a single instance of IDS, you only need one service on the machine. > 2. Can the sqlexecd check if it's already running a service or will I > run into trouble if the sqlexecd is acciedently started twice with the > same arguments? The second sqlexecd won't start; the port (service) will already be in use. > 3. IDS can use raw disk space. Will this be noticably faster than > using the unix filesystem (I would think so, but will it be only 20% > or doubling/tripling the speed)? Faster, yes. How much depends on how much other disk activity occurs on the system. Raw i/o does not go through the kernel buffer pool; cooked i/o does. If you have lots of disk intensive apps running, then having the DBMS also using the kernel buffer pool leads to increased contention, meaning more reading and writing. If you have negligible other disk activity on the machine, then it may not matter so much that the kernel buffer pool is used. On the other hand, it also means an extra copy of the data (ie disk to kernel buffer pool, kernel buffer pool to application, rather than disk to application which happens with raw i/o). > 4. IDS can use disk mirroring. Instead of adding a raid system would > it be more usefull adding a 2nd disk controller and just double the > number of disks (1 disk for temporary files, 1 disk databases and this > doubled)? Go look through the news archives on DejaNews. The opinions on RAID and logical volume managers are many and conflicting. Disk mirroring prevents you from having to recover from archive if a disk goes bad. If you have a hard 24x7 uptime requirement, you'll using some sort of mirroring. Whether you choose Informix or system or hardware mirroring is another issue. Happy hunting. > 5. Is the 'archive' backup program part of the IDS or is this a > separate product? The "Getting Started" does not answer this. There are 3 backup systems for IDS in general: ontape onarchive onbarAll of them come with IDS, I think (I'm not certain; it is not an area where I'm as current as I probably should be), though you need some auxilliary software (ISM - Independent Storage Module, or some such) with onbar. It isn't clear how big your database will grow; at only a couple hundred MB, ontape may be adequate. Otherwise, investigate onbar. I believe the consensus is that onarchive should be avoided whenever possible -- which it is since your system is new. > Is there anything obviously I'm missing on planning this? > > TIA for all your answers > > Axel (sunday and time for the Admin Guide - only 1200 pages to go) -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>

On Sun, 23 May 1999 16:03:54 -0700, Jonathan Leffler <jleffler@earthlink.net> wrote: ...many helpfull hints... fast and competent... great >I believe the consensus is that onarchive should be avoided whenever good to know that. >> Axel (sunday and time for the Admin Guide - only 1200 pages to go) Axel (at page 507 and still counting...)