need refresher on DBSERVERNAME/ALIASES/NETTYPE/SQL
Hello, Please point me to a good refresher document about setting INFORMIXSERVER and it's relation to DBSERVERNAME/ALIASES and relation to NETTYPE and relation to SQLHOSTS... the system i have inherited seems to have all users log in to the onsoctcp connection instead of shared memory.... system is HP-UX Risc, running Informix 11.70.FC1GE. but all our users open terminal sessions to the informix DB engine server so why not have them connect through shared memory? wouldn't shared memory be faster? is there a limit to the number of people who can connect via shared memory? Thanks for the help/refresher on this, it has been a long time since I have had to think through this concept. Norma Jean (NJ) Sebastian --0016e6476306e906f004a134883c
On Mon, Apr 18, 2011 at 10:15, Norma Jean Sebastian <njiiug@gmail.com>wrote: > Hello, > > Please point me to a good refresher document about setting INFORMIXSERVER > and it's relation to DBSERVERNAME/ALIASES > DBSERVERNAME is the 'official name' for the server. DBSERVERALIASES are alternative names for the server. The DBSERVERNAME and each of the DBSERVERALIASES must appear in the sqlhosts file. The INFORMIXSERVER setting controls which of the server aliases (now counting the official name as one of the aliases) is used when you say "connect to 'database'" without specifying server. The system identified by $INFORMIXSERVER must be up and running even if you specify "connect to 'database@server'". > and relation to NETTYPE > Each server alias needs something to listen to connections of that type -- and those configurations are controlled by NETTYPE. > and relation to SQLHOSTS... > > the system i have inherited seems to have all users log in to the onsoctcp > connection instead of shared memory.... > system is HP-UX Risc, running Informix 11.70.FC1GE. > > but all our users open terminal sessions to the informix DB engine server > so > why not have them connect through shared memory? > wouldn't shared memory be faster? > YMMV. Maybe. Less secure - anyone can read any shared memory communications - if they put their mind to it. The ipcstr is a secure local communication; so is soctcp when the host is local since the networking software won't send the data over the network when the connection is to a port on the local machine. > is there a limit to the number of people who can connect via shared memory? > You can only have one shared memory server alias per server (IDS instance). The NETTYPE parameters for that impose an upper bound on the number of users that can connect. The network (olsoctcp) connections and streams (olipcstr) connections do not impose upper bounds. If the amount of work grows larger than specified by the NETTYPE entry, a new poll thread is started. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --bcaec5215a3ff0950b04a134d773
I don't recall having see one recently... On Mon, Apr 18, 2011 at 6:15 PM, Norma Jean Sebastian <njiiug@gmail.com>wrote: > Hello, > > Please point me to a good refresher document about setting INFORMIXSERVER > and it's relation to DBSERVERNAME/ALIASES > and relation to NETTYPE > and relation to SQLHOSTS... > > the system i have inherited seems to have all users log in to the onsoctcp > connection instead of shared memory.... > system is HP-UX Risc, running Informix 11.70.FC1GE. > > but all our users open terminal sessions to the informix DB engine server > so > why not have them connect through shared memory? > Some people argue about security... > wouldn't shared memory be faster? > I've seen contradictory cases, but haven't investigate them.. > is there a limit to the number of people who can connect via shared memory? > The number you use in NETTYPE for connections. For TCP it's just used to make some calculations, but for shared memory it's a real limit. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --0015174bee0cbb141a04a134eedf
2008 was a IIUG presenatation if I remember right. Mit freundlichen Grüßen Joerg Volz ----------------------------------------------------------------------------- -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Fernando Nunes Sent: Monday, April 18, 2011 7:45 PM To: ids@iiug.org Subject: Re: need refresher on DBSERVERNAME/ALIASES/NET.... [23446] I don't recall having see one recently... On Mon, Apr 18, 2011 at 6:15 PM, Norma Jean Sebastian <njiiug@gmail.com>wrote: > Hello, > > Please point me to a good refresher document about setting INFORMIXSERVER > and it's relation to DBSERVERNAME/ALIASES > and relation to NETTYPE > and relation to SQLHOSTS... > > the system i have inherited seems to have all users log in to the onsoctcp > connection instead of shared memory.... > system is HP-UX Risc, running Informix 11.70.FC1GE. > > but all our users open terminal sessions to the informix DB engine server > so > why not have them connect through shared memory? > Some people argue about security... > wouldn't shared memory be faster? > I've seen contradictory cases, but haven't investigate them.. > is there a limit to the number of people who can connect via shared memory? > The number you use in NETTYPE for connections. For TCP it's just used to make some calculations, but for shared memory it's a real limit. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --0015174bee0cbb141a04a134eedf ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. IT Handel und Beratung Jörg Volz Bernhard-Früh-Str. 7 77855 Achern GERMANY Tel: +49 (0)7841-681651 Fax: +49 (0)7841-681654 Mobil: +49 (0)170-2989757 VAT-ID: DE201383541 http://www.it-volz.de
In some specific versions of IDS using Shared Memory for a large number of connections was attributed to the engine crashing; it may be that your predecessors came accross this issue and configured sqlhosts to use soctcp. I do not know if this issue exists with your current version of the engine. Regarding the relationship between configuration items:- - INFORMIXSERVER is a pointer to matching entry/entries in SQLHOSTS which specifies the connection type and attributes for connecting to a specific engine (or group of engines). - DBSERVERNAME/ALIASES are also pointers to (the same) matching entries in SQLHOSTS and are used to specify which connections to listen to. - NETTYPE specifies the number of threads listening for a connection type and the maximum number of connections each thread can handle. It also specifies whether the thread runs on a CPU VP or NET VP. Assuming your engine has sufficient shm listeners already configured you may be able to affect a change to shm connectivity simply by:- 1. Change the connector type in SQLHOSTS from onsoctcp to onipcshm (or onipcstr if you wish to use streams) --- please verify the connector type names before proceeding. 2. Bounce the engine. Regards, Nick On 18 April 2011 18:15, Norma Jean Sebastian <njiiug@gmail.com> wrote: > Hello, > > Please point me to a good refresher document about setting INFORMIXSERVER > and it's relation to DBSERVERNAME/ALIASES > and relation to NETTYPE > and relation to SQLHOSTS... > > the system i have inherited seems to have all users log in to the onsoctcp > connection instead of shared memory.... > system is HP-UX Risc, running Informix 11.70.FC1GE. > > but all our users open terminal sessions to the informix DB engine server > so > why not have them connect through shared memory? > wouldn't shared memory be faster? > is there a limit to the number of people who can connect via shared memory? > > Thanks for the help/refresher on this, it has been a long time since I have > had to think through this concept. > > Norma Jean (NJ) Sebastian > > --0016e6476306e906f004a134883c > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Nick Lello | Web Architect o +44 (0) 8433309374 | m +44 (0) 7917 138319 Email: nick.lello at rentrak.com RENTRAK | www.rentrak.com | NASDAQ: RENT --bcaec520f0216b047f04a143339c