Free Oracle Tips

Oracle Consulting Oracle Training Development
Oracle Training
SQL Tuning Consulting
Oracle Tuning Consulting
Data Warehouse Consulting
Oracle Project Management
Oracle Security Assessment
Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Internals Magazine
Oracle Links
Oracle Monitoring
Remote Support Benefits
Remote Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 


        
 

     Oracle Features of SQL*Net version 1

When a connection is made to SQL*Net, it passes the request to its underlying layer, the TNS, where the request is transmitted to the appropriate server.  At the server, SQL*Net receives the request from TNS and passes the SQL to the database. TNS is the “transparent network substrate”; a single, common interface to all protocols.  TNS has the ability to connect to databases in physically separate networks.  At the lowest level,  TNS communicates to other databases with message level send-receive commands.

 

Client side - The User Programmatic Interface (UPI) is the central client component.  The UPI converts SQL to associated parse, execute and fetch statements.  The UPI parses the SQL, opens the SQL cursor, binds the client application, describes the contents of returned data fields, executes the SQL, fetches the rows and closes the cursor.  Oracle attempts to minimize messages to the server by combining UPI calls whenever possible.

 

Server side - The Oracle Programmatic Interface (OPI) is the central server component.  The OPI is the obverse of the UPI;  it responds to all possible messages from the UPI and returning requests.

 

For server to server communication there is no UPI, instead there is a Network Programmatic Interface (NPI) at the initiating server.  SQL*Net supports network transparency such that the network structure may be changed without effecting the SQL*Net application. Location transparency is achieved with database-links and synonyms.

 

SQL*Net v 1 was the first attempt by Oracle at database connectivity.  In SQL*Net v 1, database connections requires that the request supply all of the connection information.  This includes the protocol, the host name (or IP address) and the database name.  To connect to the “tom” database on the dilbert server using TCP/IP, you would set a UNIX environment variable called TWO_TASK.  When the request is made SQL*Net v 1 will interrogate the contents of TWO_TASK to get the database information.

 

For example, let’s make a connection from the fred server to the dilbert server, and connect to the “tom” databases using TCP/IP:

 

Fred> export TWO_TASK=t:dilbert:tom

fred> sqlplus /

 

SQL*Plus: Release 3.3.4.0.0 - Production on Thu Mar 18 08:25:30 1999

 

Copyright (c) Oracle Corporation 1979, 1996.  All rights reserved.

 

 

Connected to:

Oracle7 Server Release 7.3.4.0.0 - Production

With the distributed option

PL/SQL Release 2.3.4.0.0 - Production

 

SQL> select * from v$database;

 

NAME      CREATED              LOG_MODE     CHECKPOINT_CHANGE# ARCHIVE_CHANGE#

--------- -------------------- ------------ ------------------ ---------------

TOM       06/13/98 19:00:26    NOARCHIVELOG         2.8713E+12      2.8713E+12

 

 

One of the biggest shortcoming of SQL*Net v 1 was the requirement to “know” all of the connection information, instead of having a look-up file to get this information.  In SQL*Net version 2 we see this information.


 

Free Oracle dictionary reference poster

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

North Carolina Oracle Users Group

 

 Arabian horse breeder

Seeing eye horses

 

 

 

 

 

BC Remote Oracle Support
P.O. Box 511 • Kittrell, NC, 27544

Copyright © 2007 by Burleson Enterprises, Inc. All rights reserved.