Configuration and Connection Questions

[BCM]

I apoligize if these questions have been asked/answered before.

Question #1:
When a Progress database is configured to spread tables across multiple schema areas does Progress allocate separate memory regions for the respective schema areas or does memory remain a 'stew' of the current physical blocks read from disk?

Question #2:
It has been recommended to me to improve processing performance by executing 4GL code from the same box as the database so that the 4GL code can use shared memory rather than communicating via TCP/IP. The recommendations suggested having the 4GL client connect without using the -H and -S parameters. How can this be done with a database running in multiuser mode?

 

[Casper]

Hi BCM:

I'll try to answer your questions:

1:
Using different area's has no effect on the shared memory. All data is still kept in the same shared memory. (and no preloading of tables possible like some other database engines has :awink: )

2:
Instead of connecting with -H and -S you can connect with just using -db path_to_database/databasename

HTH,

Casper.

 

[joey.jeremiah]

Using different area's has no effect on the shared memory. All data is still kept in the same shared memory.

not yet. but shared memory by area or object is coming

i don't know how much of a problem it is. is there some specific bottle neck ?

if it is you might want to look into private read-only buffers.

(and no preloading of tables possible like some other database engines has :awink: )

dont wind him up


tunning your database isn't necessarily a big job or lots of work

but you might want to get a progress consultant to give you a hand.

 

[BCM]

Thank you.

I'm still not clear with regard to the connection question. Casper, are you saying that a 4GL program running on the same box as the database may connect to the database in a multiuser mode with -db <database location and name>?

 

[Casper]

Thank you.

I'm still not clear with regard to the connection question. Casper, are you saying that a 4GL program running on the same box as the database may connect to the database in a multiuser mode with -db <database location and name>?

Yes, from the OpenEdge Getting Started: Installation and Configuration for UNIX:

mpro [ db-name ] [ parameters ]


db-name
Specifies the database you want to start. If the database is not in the current directory, you must specify the full pathname of the database.
parameters
Specifies the startup parameters you want to use.​

On UNIX, the MPRO command starts either a local or remote client. If the Host Name (-H) and Service Name (-S) parameters are supplied, OpenEdge starts a remote client—a client that is assigned to a server. Otherwise, OpenEdge starts a local self-service client. Note that specifying -H and -S when starting a client on the local host machine actually produces a “local remote client” (a local process that accesses the database through a server.)
The database you name when starting multi-user OpenEdge must be in the current directory, or you must specify the full pathname of the database. For example, if you are using UNIX and you log in as sue, the login directory is /usr/sue.

Joey:

In what release are they planning to do this? I heard of it a few times but never heard a specific version in which it is going to be released.

(Same with gui and referential integrity).

 

[Lee Curzon]

I'm still not clear with regard to the connection question. Casper, are you saying that a 4GL program running on the same box as the database may connect to the database in a multiuser mode with -db <database location and name>?

Hello BCM,

-H, -S (Host/Service etc/hosts, etc/services, I think on Unix) just tell the connecting (remote) process how to find the database, and are not needed if the DB is running locally, because you can supply the pathname directly.

Processes can't connect single user (use -1 parameter), by definition, to a database running in multi-user mode.

Processes can't connect at all to a database running in single user mode if another user is already connected.

There may be a requirement for databases to be running multi-user to allow remote connections, I can't remember, someone else remind me please.

The reverse requirement you imply (local connections require single user) is absolutely not so. Development on my disconnected laptop would be a PITA if that were so.


HTH

 

[joey.jeremiah]

Hi Casper

In what release are they planning to do this? I heard of it a few times but never heard a specific version in which it is going to be released.

not something i was particularly waiting for


but heres an excerpt from Tom's post

<quote>

18) OE DB Roadmap -- This is about half looking back and reminding us
(or teasing those who are on older releases) and then Rich Banville gets
up and tells us what's coming. I'll skip the stuff we already have...
there were, of course, all sort of caveats but no shrink wrap NDA that
so here's what I scribbled:

10.1B (referred to as a "limits" release, primarily removing and
extending various limits & restrictions)

- Enable AI Online
- Table & Index IO by User VST !!!!!!!!!! Thank you, thank you, thank
you!!!!! Now how about "what program is the user running? and what
line? and what is the query string? ;-)
- Large keys (2000 byte indexes -- needed for unicode, not supported for
1k & 2k databases)
- Large shared memory
- 64 bit rowid, integer & sequences (plus a magic conversion from 32 bit
integers)
- 32,000 areas
- DataExtend integration
- Temp table database => 4k or 8k
- Adaptive transactions (not explained, back ported to 10.0b05)
- SQL query timeout
- SQL multi-db query
- SQL order-by, group-by
- SQL select-top
- SQL wide table support

Beyond 10.1B (on the roadmap but less clear on the details)

- Table partitions
- SQL/XML/Xquery
- Stats daemon
- Star Schema
- SQL multi-statement execution (*not* in parallel)
- Federated ID management
- Unified authorization management
- Column encryption
- SQL roles
- Secure utilities
- Referential integrity
- Alter -B, -L, -n etc online (probably upward only)
- Online index deactivation
- Self healing db
- Parallel server (*way* out there but finally on the radar!
ObjectStore influence?)
- Runtime SQL stats
- Transact SQL
- Multiblock IO (and larger blocks)
- More automatic tuning
- Increased concurrency
- Threaded utilities (at the "object" level -- aka threads per table or
index).
- "Snap Backup" certifications.
- Very Large Memory
- Big B by area or object (and possibly other appropriate parameters).

</quote>

(Same with gui and referential integrity).

not very soon. late 2007, very late 2007, or so i heard


i haven't seen the prototype demo at exchange and i dont know enough
about it.

but i hope it wont be too much of a hurried release and will have enough
basic functionality to make it useful.

if for example it wont have a resizing scheme, i believe, it will be another
traumatic experience for many of us.

an interesting aspect of it is that it opens the possibility in the future for
pda's and other devices.


sounds like theres alot of exciting work being done with user interfaces,
including ajax.

 

[BCM]

I'm sorry to be so dense in the head about this connection stuff. Our Progress database is running in multi-user mode. It is started from the Progress Explorer. Once a broker is started for the database how can a program connect to the database with the -db command and avoid the broker?

 

[Casper]

Hi Joey:

I knew I read it somewhere and it was in Tom's post regarding Exchange Thanks for refreshing my mind. (And yes I found it again somewhere in my lots and lots of interesting PEG mail I try to archieve in an orderly fashion

To BCM:

If I read your first post correctly then you just want to establish a self service client connection, don't you?

If so then just get rid of the -S -H (-N) parameters in your normal connection statement for the client process which runs the 4GL procedure and replace databasename with path_to_database/databasename and you have a self serving client which connects directly with shared memory, without the intervention of a server proces (which are used for remote connections).

HTH,

Casper.

 

[BCM]

Casper,
I was not aware that both a self service client connection and remote connections be made at the same time. Can they?

 

[Casper]

Yeah sure, without a problem.

Casper.

 

[BCM]

Thank you. We will try this.

 

[joey.jeremiah]

I'm sorry to be so dense in the head about this connection stuff. Our Progress database is running in multi-user mode. It is started from the Progress Explorer. Once a broker is started for the database how can a program connect to the database with the -db command and avoid the broker?

the server code is part of the virtual machine or client

funny, client with no server



from the database admin guide

<quote>

The OpenEdge RDBMS architecture supports self-service and network clients. A
self-service client is a multi-user session that runs on the same machine as the broker.
Self-service clients access the database directly through shared memory and not through
servers, because server code is part of the self-service client process. Self-service clients also
perform server and client functions in one process, and they execute application logic. On
shared-memory UNIX and Windows systems, the database engine provides self-service clients
with nearly simultaneous access to the database.

A network client can be local or remote but cannot connect to a database directly; rather it must
use a server. The network client accesses the database through a server process that the broker
starts over a network connection. The network client does not have access to shared memory,
and it must communicate with a server process.

</quote>

bcm,

do you have a descent pc you can spare to do a few tests ?