Re: Oracle->Btrieve

On Mon, 19 Mar 2001 17:14:16 -0700, "Ilya Kuzkin" <elliew_at_hotmail.com> wrote:

>Hi, All!
>
>Might happen that we will choose a different client application which is
>built on Btrieve API and eventually requires a Btrieve backend. We are
>running Oracle 8.0.5 now. I've found some information about binding Btrieve
>and Oracle but couldn't really find any description of different concerns
>and possible problems. So, here I am.
>
>My own concerns are :
>
>a) is Btrieve/Pervasive able to store tables and manage indexes of the
>tables of 40-50 mln records (20-40 columns) in multi-user environment. The
>current nature of an application is as follows: several processes are
>working extensively on importing, querying, modifying and making heavy
>calculations on the data. And, yes, some of the tables are 40 mln records. I
>am not really sure about new application, but I believe, architecture will
>be the same (or similar).
>

40-50 M records are not a problem, but there is a per table (logical file) size limitation of 64 GB (based on the current file format and a 4K page size) if the records are large, or have many large indexes, could hit that 64GB limit.

20-40 columns per table is not an issue either. Currently 255 are supported through the relational SQL API, to be changed upward in SP3 due out shortly.

Architecturally there is no real upper limit on number of columns through the Btrieve API per table, but there is a 119 index segment limit that must fit on the ~4080 byte fixed record segment length. Each record may contain a 2GB variable length segment.

>b) Should I expect any productivity decrease under the conditions stated
>above after switching to Btrieve/Pervasive

Probably not... probably just the opposite, but I honestly do no know what numbers you are used to, or the hardware you are running.

The Pervasive.SQL 2000 Btrieve API usually runs around 1000 Btrieve operations a second on desktop class hardware. Certain bechmark numbers hit 6000+ again on desktop machines, locally (no network hop).
Real world servers have hit 1000+ sustained with debug tracing turned on.
Though it may take several (3 minimum) Btrieve operations for a true transaction, transactions are not required.

Bottom line, it depends on how well the application is written ( e.g. if it scans through all 40M records for each transaction, all bets are off) , hardware platform (not fair running a 486/33 w 32MB (yes it is supported) against a quad Xeon 866 with 4GB (also supported)), and tuning (yes it is possible to choke the engine or OS).

>
>c) Can anybody mention any benefits (I'm aware about the price quotes
>difference).

Ease of use, "Zero DBA" is pretty close, plenty of free time.

In SP3 there will be an Auto-Reconnect feature for those less than perfect networks.
>
>d) I know it's not quite correct to compare full-flavored server database
>such as Oracle and desktop like database like Btrieve, but, I believe this
>is not completely in my power to cancel management directives.

Under most circumstances the Pervasive.SQL engine is set and forget.
>
>e) If you think of any info I haven't asked above but which you may think
>might be useful for me (vow!) just let me know.
>

Just curious,
How many concurrent "live" users?
1000+ on a good server is not unreasonable, yes they exist.

How many concurrent "process" users?
20+ on a good server is not unreasonable, they also exist.

What server OS platform NT/Win2K, NW, Linux, Solaris?

>Thanks in advance,
>Ilya.
>
>FBC Inc.

I do not monitor the Oracle newsgroup.

Leonard Received on Mon Mar 19 2001 - 20:23:21 CST