Re: Anyone using SQL*Net successfully?

In article <1992Jun26.193236.1_at_cc.helsinki.fi>, you write:
|> Dear netters,
|>
|> we are gathering information on using Oracle with SQL*Net. Our system
|> would consist of:
|>
|> * 50 .. 100 386SX/16 MHz PS/2 micros with minimum of 4 MB RAM
|> * Token Ring or Ethernet
|> * UNIX box as a server

The system I set up was similar to this but used fewwer client PC's. I used the WD8003E 8-bit ethernet card on thin wire and a SCO ODT 1.1 file/database server (X not usually running) ( 386-33 with 2 Gb of SCSI storage and 16 Mb RAM )
connected to 4Mb RAM 386 clones running DOS 3.3, 4.01 and 5.0 and MS-Windows 3.0. The TCP/IP package for the DOS machines was Wollongong Pathway Access 2.0 which turned out to be pretty fast and has the smallest memory footprint yet. Loaded SQL*Net in the WINSTART.BAT file (a Windows thing).

Being a small net (20 local users), I also configured the SCO box as a file server (with Wollongong's NFS product on the DOS side) and a print server.

Unix clients might be faster.....just a suggestion.

|>
|> The name of the game is that all Forms are run on the PCs and all data
|> resides on the server. The user can run SQL*Plus and ReportWriter
|> reports either on the PC or on the server. The users DO NOT use any
|> terminal sessions of any kind - the only way PCs and the server
|> communicate is via SQL*Net.
Sounds like you want religiously pure client-server. Good...

|>
|> We are not sure whether this really works with current Oracle versions
|> (RDBMS 6, SQL*Net 1.1, SQL*Forms 3.0). SO IF YOU HAVE TRIED THIS KIND OF
|> A CONFIGURATION, COULD YOU PLEASE ANSWER THE FOLLOWING QUESTIONS:
|>
|> 1. Are you satisfied with the response time, especially with forms using
|> many SQL statements? An interesting example would be a form with a
|> POST-QUERY trigger which executes many SQL statements for each record
|> fetched or a multi-SQL-statement commit-time trigger.
Have you tried tuning your Oracle instance ? Unix (esp for multi-users)? Your SQL?

|>
|> 2. What is your connect time? I mean if you start an oracle session with
|> SQL*Plus or SQL*Forms, how long does it take before you are connected?

Virtually instantaneous.
How many simultaneous ACTIVE oracle users? What kind of Unix db server?

|> 4. What is your exact configuration? SQL*Net over which protocol?

SQL*Net for TCP/IP 1.1 on SCO, using SCO's TCP/IP, over thin wire ethernet, connecting to Wollongong's Pathway Access 2.0 TCP/IP with SQL*Net 1.1 for DOS (special version for Wollongong [the old one works fine] ) and various DOS versions, though 5.0 is most prevalent. The slowwest DOS machine is a 386/25. with 4Mb ram.  

|> I'm asking only subjective answers to questions 1 and 3 because you
|> really can't compare objective times without long explanation about what
|> kind of an operation was performed.
|>
|> I have seen a system like this which used an IBM 4381 mainframe as a
|> server running RDBMS 6.0, SQL*Net for APPC 1.1 and Forms 3.0 on PCs. The
|> response time for questions 1 and 3 was bad and connect time was over 30
|> seconds. A single SQL statement took generally at least 2 seconds to
|> execute, and a trigger with 6 SQL statements took at least 17 seconds to
|> execute. This was measured on a weekend, when CPU load was very low (the
|> tester was practically the only user!) and the SQL statements returned
|> just a single row each and used carefully tuned indexes! So I want to
|> know if there are better configurations or should I forget SQL*Net for
|> heavy production use.

Hint for lots of users: Do what I did to tune your Oracle -- find a typical transaction or two, write a Pro*C program to preform it (them), wait a specified number of seconds after the response comes back, and repeat. Spool the output to a file (integer time (minutes), response time (seconds), and rows returned). Then have an increasing number of workstations run this program (a script to do this sure makes it easy) with a pre-determined amount of time between additional users.

Take avg, max, and min response time and plot response vs. # users.

We found that giving Oracle too much memory cause exponentially decreasing performance over 12 users. This is also useful when comparing machines... Be sure to run vmstat during your test, some Oracle TWO_TASK processes can eat serious memory on some (SunOS 4.1.0) unixes with some processors (SPARC-1, Auspex).

|> Please reply via e-mail. I will summarize if anyone requests.
|>
|> Thanks in advance!
|> --
|> Juhani Jaakola
|> jaakola_at_cc.helsinki.fi

-- 

#########################################################
David E. Trum
Database Administrator		Email:  uunet!srg!dtrum
ARINC Research Corporation	Phone:  (410)266-4772
2551 Riva Road  MS 5-230	Fax:    (410)573-3024
Annapolis, MD  21401-7461
#########################################################



-- 

#########################################################
David E. Trum
Database Administrator		Email:  uunet!srg!dtrum
ARINC Research Corporation	Phone:  (410)266-4772
2551 Riva Road  MS 5-230	Fax:    (410)573-3024
Annapolis, MD  21401-7461
#########################################################
--

#########################################################
David E. Trum
Database Administrator		Email:  uunet!srg!dtrum