47 A2 13UR Rev00 Database Products Bull DPS 7000 User's Guide SQL *Net V1 with ORACLE7 GCOS 7 Software Subject: This guide is intended to provide all the information necessary to use SQL *Net V1 facilities with ORACLE7 under the GCOS 7 operating system and from a Personal Computer under MS-DOS. Special instructions: New version for ORACLE7 server. Software supported: GCOS 7 Release V6. Date: October 1993 Bull S.A. Bull HN Information Systems Inc. CEDOC Publication Order Entry Atelier de reproduction MA30/843 331, Avenue Patton BP 428 300 Concord Road 49005 ANGERS Cedex Billerica, MA 01821 FRANCE U.S.A.
Transcript
47 A2 13UR Rev00
Database Products
Bull DPS 7000User's GuideSQL *Net V1 with ORACLE7
GCOS 7
Software
Subject: This guide is intended to provide all the information necessary touse SQL *Net V1 facilities with ORACLE7 under the GCOS 7operating system and from a Personal Computer under MS-DOS.
Special instructions: New version for ORACLE7 server.
Software supported: GCOS 7 Release V6.
Date: October 1993
Bull S.A. Bull HN Information Systems Inc.CEDOC Publication Order EntryAtelier de reproduction MA30/843331, Avenue Patton BP 428 300 Concord Road49005 ANGERS Cedex Billerica, MA 01821FRANCE U.S.A.
Copyright Bull S.A., 1993
Bull acknowledges the rights of proprietors of trademarks mentioned herein.
Printed in France
Suggestions and criticisms concerning the form, content, and presentation ofthis manual are invited. A form is provided at the end of this manual for this
purpose.
Bull disclaims the implied warranties of merchantability and fitness for aparticular purpose and makes no express warranties except as may be stated inits written agreement with and for its customer. In no event is Bull liable toanyone for any indirect, special, or consequential damages.
The information and specifications in this document are subject to changewithout notice. Consult your Bull Marketing Representative for product or serviceavailability.
47 A2 13UR Rev00 iii
Preface
SCOPE AND OBJECTIVES
This guide is intended to provide all the information necessary to use the SQL*Netfacilities with ORACLE7 (R) under the Bull GCOS 7 Version 6, and from a PC with asynchronous or asynchronous communication link under MS-DOS.
INTENDED READERS
This guide can be used by anyone wishing to perform networking operations withORACLE products. The information contained in this guide is relevant to applicationprogrammers and administrators; end-users who are already familiar with SQL*Plus willalso find it useful.
STRUCTURE OF THIS DOCUMENT
Section 1 contains an overview of the SQL*Net facilities. It explainswhat distributed processing is, and introduces the SQL*Netarchitecture.
Section 2 describes the architecture SQL*Net uses to provide anetworking environment for ORACLE. It addresses topicssuch as database specification, the COR CommunicationsManager, and restrictions imposed by SQL*Net.
Section 3 provides information on how to access a remote databasevia SQL*Plus, and via the Pro* series precompilers. Thenetworking features of the SQL*Plus language areoutlined.
Section 4 provides complete instructions for installing and using theasynchronous driver and the synchronous driver on a PC.In addition, manual log-on and autologon are described.
SQL*Net V1 with ORACLE7 User's Guide
iv 47 A2 13UR Rev00
RELATED DOCUMENTS
The ORACLE7 documentation set consists of the following books. Refer to theORACLE7 Documentation Catalog for more information on specific documents.
The 47 Series: GCOS 7-specific Manuals
ORACLE7 Documentation Catalog.............................................................. 47 A2 10URORACLE7 Installation Guide ....................................................................... 47 A2 11URORACLE7 Guide to Processors and Utilities ............................................... 47 A2 12URSQL*Net V1 With ORACLE7 User's Guide.................................................. 47 A2 13UR
The 86 Series: General Manuals
SQL Language Reference Books (2)
ORACLE7 Server SQL Language Reference Manual ...................................86 A2 43PEORACLE7 Server SQL Language Quick Reference .....................................86 A2 47PE
PL/SQL (1)
PL/SQL User's Guide and Reference ..........................................................86 A2 76SW
General RDBMS and Utilities (6)
ORACLE7 Server Concepts Manual.............................................................86 A2 40PEORACLE7 Server Administrator's Guide ......................................................86 A2 41PEORACLE7 Server Application Developer's Guide .........................................86 A2 42PEORACLE7 Server Messages and Codes ......................................................86 A2 45PEORACLE7 Server Utilities User's Guide .......................................................86 A2 44PEORACLE7 Server Migration Guide ...............................................................86 A2 46PE
2.1.1 Terminal-to-Process Communication .................................................................. 2-32.1.2 Task-to-task Communication ............................................................................... 2-4
2.2 COR AND OPEN7 .................................................................................................. 2-4
2.2.1 Enabling Remote Connections ............................................................................ 2-42.2.1.1 Remote Connections Using COR I .......................................................................... 2-42.2.1.2 Over TCP/IP ........................................................................................................... 2-4
3.1 USING SQL*PLUS WITH SQL*NET ...................................................................... 3-1
3.1.1 Distributed Queries ............................................................................................... 3-13.1.2 Logging On To SQL*Plus Under SQL*Net from a DPS 7000 .............................. 3-23.1.3 The CONNECT Command .................................................................................... 3-33.1.4 The COPY Command ............................................................................................ 3-43.1.4.1 Error Reporting ....................................................................................................... 3-63.1.4.2 COPY Examples..................................................................................................... 3-83.1.4.3 Macro Substitution .................................................................................................. 3-93.1.4.4 Effect on Open Transactions in SQL*Plus............................................................... 3-93.1.4.5 Internals.................................................................................................................. 3-10
Table of Contents
47 A2 13UR Rev00 ix
3.1.5 Database Links ..................................................................................................... 3-113.1.5.1 The CREATE DATABASE LINK Command ............................................................ 3-123.1.5.2 The DROP DATABASE LINK Command ................................................................ 3-15
3.1.6 Querying Remote Tables ...................................................................................... 3-153.1.7 Creating Synonyms for Remote Tables ............................................................... 3-163.1.8 Creating Views for Remote Tables ...................................................................... 3-173.1.9 Deleting from a Remote Table .............................................................................. 3-173.1.10 Inserting into a Remote Table .............................................................................. 3-173.1.11 Copying from a Remote Node to a Local Node ................................................... 3-183.1.12 Restrictions on Database Object Names ............................................................. 3-183.1.13 Restrictions on Distributed Queries .................................................................... 3-183.1.14 Links are Stored in the Data Dictionary ............................................................... 3-19
3.2 USING THE ORACLE PROGRAMMATIC INTERFACES WITH SQL*NET ............ 3-20
4. SQL*Net on a PC Under MS-DOS (synchronous and asynchronousprotocols) .......................................................................................................... 4-1
4.3.1 Manual Log-on ...................................................................................................... 4-84.3.1.1 Once the SQL*Plus Processor has been Called ...................................................... 4-94.3.1.2 As Soon as Connection is Made.............................................................................. 4-104.3.1.3 When Connected to ORACLE Server on PC........................................................... 4-104.3.1.4 Disconnection ......................................................................................................... 4-10
4.3.2 Autologon ............................................................................................................. 4-114.3.3 Autologon Dialog Description ............................................................................. 4-124.3.3.1 The instruction line.................................................................................................. 4-134.3.3.2 Special characters .................................................................................................. 4-144.3.3.3 A simple example ................................................................................................... 4-144.3.3.4 Default autologon files ............................................................................................ 4-144.3.3.5 A sample autologon file........................................................................................... 4-15
SQL*Net V1 with ORACLE7 User's Guide
x 47 A2 13UR Rev00
4.3.4 Using Macro Variables .......................................................................................... 4-154.3.4.1 Defining macros...................................................................................................... 4-154.3.4.2 Further information ................................................................................................. 4-16
Index ............................................................................................................. i-1
Table of Contents
47 A2 13UR Rev00 xi
Illustrations
Figures
2-1 The Client/Server Model of Communication............................................................ 2-32-2 SQL*Net Connections over DSA............................................................................. 2-62-3 SQL *Net Connections over TCP/IP........................................................................ 2-74-1 MS-DOS Files and Directories Under SQL*NET ..................................................... 4-19
ex "SQL*Net Overview"This section provides an introduction to SQL*Net, and includesthe following information:
• Prerequisites for using SQL*Net
• A general description of SQL*Net and its applications
• A discussion of the advantages of using SQL*Net
• A summary of SQL*Net features.
1.1 PREREQUISITES
ex "SQL*Net Prerequisites"To perform networking operations with SQL*Net, you musthave:
• Version 1.1 (or later) of SQL*Net
• Version 6.0 (or later) of the ORACLE RDBMS.
SQL*Net is provided as part of the ORACLE RDBMS. Installation of SQL*Net isdescribed in the ORACLE7 Installation Guide
SQL*Net over TCP/IP requires GCOS 7 Version 5 and the OPEN7 package.
NOTE: The ATLANTIS card is mentioned in examples throughout this manual. Thereare, however, other cards which carry out the same functions.
SQL*Net V1 with ORACLE7 User's Guide
1-2 47 A2 13UR Rev00
1.2 WHAT IS SQL*NET?
ex "Architecture"SQL*Net is a software layer that cooperates with the communicationprotocols supported by various operating systems to provide a distributed processingenvironment for the ORACLE Relational Database Management System (RDBMS). As aresult, the boundaries between diverse hardware and operating system types in anetwork are virtually eliminated.
Prior to ORACLE-V5, the ORACLE architecture allowed applications to connect only to asingle, predefined database at a single, predefined network location. Further, applicationprograms had to reside on the same CPU as the database. SQL*Net was introduced withVersion 5.0 of the ORACLE (RDBMS), as an optional software product that allows anapplication program running on one machine to access and manipulate data in anORACLE database that resides on another machine. The application program in thiscase can be either an ORACLE utility such as SQL*Forms, or it can be an applicationthat was developed using the ORACLE Programmatic Interfaces. In addition, SQL*Netallows applications to dynamically connect to multiple ORACLE databases acrossnetwork nodes, using a variety of communication protocols.
1.3 DISTRIBUTED PROCESSING AND SQL*NET
ex "Distributed database processing"Distributed processing is the process wherebyprograms on different network nodes co-ordinate their operations by sending messagesacross the network. The users of a distributed processing environment must be able toidentify the location of the remote database and must send messages across the networkto initiate a process on the remote database. In contrast, a distributed database co-ordinates shared access on behalf of the users, and the location of the data is actuallytransparent to the user.
A distributed processing environment generally does not support joins across thenetwork, nor does it support statements that reference more than one node in a singlestatement.
SQL*Net allows applications to reside on a machine other than where the database islocated, and provides a means of moving data from one node to another on the network.SQL*Net can be used by ORACLE applications to provide the features associated withdistributed processing (accessing data in a remote location and so on). In addition, thedistributed query capability provided by the ORACLE kernel allows a single SQLstatement to reference more than one node and supports joins across the network. It isalso possible to write applications using the ORACLE Programmatic Interfaces that allowoperations to span more than one network node.
Overview
47 A2 13UR Rev00 1-3
1.4 SQL*NET ARCHITECTURE
ex "SQL*Net architecture"ex "Two-task architecture"ex "Architecture"ex "client/servermodel"SQL*Net performs distributed processing by incorporating multi-node networkcommunication in the process-to-process communications permitted by ORACLE's two-task architecture. The ORACLE RDBMS is based on two-task architecture, which meansthat the user task (or application) runs as a separate operating system process from theserver task (the ORACLE kernel). These two tasks communicate by using theinterprocess communication facilities supported by the operating system.
When SQL*Net is used, this interprocess communication takes place over a networkrather than between two processes on a single machine. This is known as theclient/server model of operations. In this model, the client is an application program ortool, and the server is the ORACLE RDBMS. In a traditional single CPU environment,the client and server execute on the same machine, which also stores the database files.SQL*Net allows the client program to execute on a machine other than where the kernel(and database) reside. The client program requests the services of the server by sendingmessages across the network.
Section 2 provides a more detailed explanation of how SQL*Net uses the client/servermodel of operations to perform distributed processing.
1.5 ADVANTAGES OF SQL*NET
One of the most important features of ORACLE software is that it has the samefunctionality, regardless of the operating environment. Because of this commonfunctionality, ORACLE is ideally suited to a networking environment.
Perhaps the primary advantage of using SQL*Net to perform distributed processing isthat it encourages the efficient use of available hardware. Because SQL*Net allowsORACLE products hosted on various environments to communicate with one anotheracross the network, database administrators have the freedom to choose the mostappropriate hardware for a particular application. For example, SQL*Net allowsSQL*Calc running on a PC to access a database stored on a central system, such as amini-computer or a mainframe. This makes it possible to take advantage of the featuresof both machines: SQL* Calc uses the quick response time offered by the PC, and thedatabase utilizes the efficient data sharing techniques, rapid I/O, and inexpensiveprocessing power of the minicomputer or mainframe.
Secondly, networking is ideally suited to a database environment because it provides away of accessing data that is distributed across geographically remote locations on thenetwork. For example, by using SQL*Net it is possible to distribute departmental orregional computing requirements to small local machines, while retaining the ability toupload and download data to a large central computer for corporate processing. Aspecific example of this might be a regional sales office with a DPS 7000 connected to alarger remote DPS7000 to upload daily sales orders and download inventory and pricingdata. This example also illustrates the fact that SQL*Net encourages the efficientdistribution of data, and, hence, the data processing workload.
SQL*Net V1 with ORACLE7 User's Guide
1-4 47 A2 13UR Rev00
Another advantage of networking is that networks accommodate growth more cost-effectively than do independent computer systems. For example, it is more economicalto add PCs to a network that accesses a mainframe than to purchase a new mainframe.Networking allows smaller, less expensive computers to share the power of larger, morepowerful systems.
Another advantage of an environment that uses SQL*Net is that the applicationsgenerated using ORACLE can be accessed across the network, thus streamliningapplication development effort. Because applications generated using ORACLE are soportable, a single development effort results in a single application that operatesidentically and has the same user interface on every system on the network. Theseapplications can now be executed from any system on the network, and can access anyORACLE database. It is also possible to write high level language programs, using theORACLE Programmatic Interfaces, that include SQL*Net functions.It is even possible to write a high level language program that spans multiple networknodes-- a function not normally available.Further, the database security and integrity normally maintained at a local level ismaintained across the network.
In summary, using SQL*Net results in the following advantages:
• Processing power is utilized more efficiently
• Data processing can be distributed to remote geographic locations
• The data processing workload can be distributed more efficiently
• Growth in processing power can be handled economically
• Application development effort is streamlined
• Data security and integrity is protected across the network.
Overview
47 A2 13UR Rev00 1-5
1.6 SQL*NET FEATURES
ex "Asynchronous Protocol"ex "SQL*Net features"ex "COPY command"ex "SynchronousProtocol"ex "Ethernet LAN"ex "TCP/IP"SQL*Net offers the following features:
• A SQL*Net user anywhere on a network can connect to any other ORACLE databaseon that network, by simply logging on to the remote database.
• SQL*Net allows access to multiple databases, even simultaneously. Thus, it ispossible to use a local database some of the time, and a remote one the remainder ofthe time. Consequently, it is possible to extract data from a remote database, processit within a local database, and return it to the remote database. It is possible to usedata in one database within transactions affecting another database. Two examples ofthis are the database-to-database copy services, such as those provided by theSQL*Plus COPY command, and the ability to store static data locally for databasevalidation, while posting updates on the central database.
• The ORACLE Asynchronous Protocol and the Synchronous Protocol both provide anautologon facility that automatically logs on to the remote host whenever a connectionis requested.
• SQL*Net supports homogeneous connections (between like environments). Forexample, it is possible to connect two DPS7000s, with one acting as the client and theother as the server.
• SQL*Net also supports heterogeneous connections (between unlike environments).For example, it is possible to connect a PC to a DPS7000, with the PC acting as theclient and the DPS7000 as the server, or a UNIX system to a DPS7000 with TCP/IPon Ethernet LAN.
• Both heterogeneous and homogeneous connections can be established concurrently.
• SQL*Net operates independently from the network protocols that it supports. Thus itsfunctionality is the same, regardless of the underlying protocol.
• Log-ons can be directed to local or remote databases or to the default database.
• SQL*Net provides dynamic redirection of log-on after utility initiation. Thus, it ispossible to change from one remote host to another, while logged on to the sameORACLE application.
• When using SQL*Net, the security and automatic recovery features provided byORACLE are extended and maintained across the network.
• By using the distributed query capability provided by the ORACLE kernel, it is possibleto reference more than one node in a single SQL statement.
SQL*Net V1 with ORACLE7 User's Guide
1-6 47 A2 13UR Rev00
1.7 COMMUNICATION LINKS
ex "Communication links"ex "Ethernet LAN"ex "X25"ex "TCP/IP Protocol"ex "DSANetwork"SQL*Net supports the following communication links:
Over a DSA Network,
X25 X25 private Ethernet LAN
Over TCP/IP Protocol,
Ethernet LAN
1.8 SQL*NET DRIVER ERRORS
ex "SQL*Net driver errors"ex "Driver errors"ex "Error reporting"SQL*Net driver errors willdisplay an error code of between ORA-6000 and ORA-6049 inclusive.
These errors are listed in the ORACLE7 Server Messages and Codes manual where thecause and remedial action are documented.
1.9 ORACLE-V6/V7 COMPATIBILITY
ex "Compatibility"Using SQL*Net it is possible to have an ORACLE-V6 acting as clientwhile having an ORACLE-V7 acting as server. For example, it would be possible to useSQL*Net from a PC running ORACLE-V6 to a DPS7000 running ORACLE-V7.
NOTE: It is not recommended to reverse the roles and have the ORACLE-V7 acting asclient while the V6 is acting as server.
47 A2 13UR Rev00 2-1
2. Architecture
ex "SQL*Net over TCP/IP"ex "Architecture"ex "TCP/IP"ex "Database linksspecification"This section describes the SQL*Net architecture, and covers the followingtopics:
• The two-task communication technique used to support distributed processing
• The client/server model of communication
• Terminal-to-process communication
• Process-to-process communication
• Enabling the SQL*Net facilities with the COR command
• SQL*Net over TCP/IP
• Communication protocol primitives needed to support SQL*Net
• Specifying a remote database
• SQL*Net restrictions
• Using other ORACLE utilities with SQL*Net.
SQL*Net V1 with ORACLE7 User's Guide
2-2 47 A2 13UR Rev00
2.1 DESCRIPTION
ex "Client/server model"ex "Two-task architecture"The communication technique usedby SQL*Net is based on the two-task architecture that ORACLE uses in certainoperating environments such as UNIX. In the usual sense, two-task refers to thecommunication that takes place between two processes on the same machine. Theseprocesses communicate with one another by using the interprocess communicationfacilities supported by the operating system. With SQL*Net this technique is also used,but rather than two communicating processes that reside on a single CPU, thecommunication takes place between two processes that reside on two differentmachines. This form of a two-task architecture is known as the client/server model ofcommunication.
Although this model of communication applies even when ORACLE is running in a singlemachine environment (where the application acts as a front end process and theORACLE kernel acts as a back end process), it becomes more apparent in a networkingenvironment. In a networking environment, two tasks, each running on a differentmachine, communicate by using the various communication protocols supported bySQL*Net. One task is the client and the other task is the server. The SQL*Net client isthe application program, and can be any of the ORACLE applications, or it can be auser-developed application that uses ORACLE. The SQL*Net server is the RDBMS (theORACLE kernel).
In SQL*Net terminology, the host is the machine where the database resides and runsthe ORACLE kernel, thus supporting the server. The client is the machine where theapplication resides. It is important to note that some machines, such as a DPS 7000, orDPX/2 can act as both clients and servers. Other machines, such as a PC, can act onlyas clients. Only a machine that acts as a server can be a host.
The client can be a single user system (such as the PC), while the server must be amulti-user system (such as a DPS 7000). The chart that follows shows whichcombinations of client and server are possible:
ex "Client/server model"Table 2-1. Client/Server Mac hine Combinations Error!Reference source not found.
MACHINE CLIENT? SERVER?PC Always NoMini Yes YesMainframe Possible Usually
Architecture
47 A2 13UR Rev00 2-3
Cl ient node Server node
O R A C L EAppl icat ion
O R A C L ED B M S
O R A C L EServerOther
NetworkSof tware
Layers
SQL*NetDriver
Communica t ionsPackage
Communica t ionsPackage
SQL*NetDriver
Communicat ions l ine
Figure 2-1. The Client/Server Model of Communication Error! Reference source notfound.
SQL*Net supports two forms of the client/server model of communication: terminal-to-process communication and task-to-task communication. The subsections that followdescribe these two forms of communication.
2.1.1 Terminal-to-Process Communication
ex "Terminal-to-process communication"ex "Asynchronous Protocol"ex "ATLANTISProtocol"When terminal-to-process communication is used, one process (the terminal) isexpected to act like a dumb terminal. A program running on the PC simulates terminalbehavior in order to communicate with programs running on the remote host. SQL*Netsupports two communication protocols that provide terminal emulation: theAsynchronous Protocol and the ATLANTIS Protocol. When either of these protocols areused, the remote host treats the client as if it were a dumb terminal, and messages mustbe sent between the client and server, in turn simulating task-to-task communication.
Section 4 provides instructions for using these protocols.
SQL*Net V1 with ORACLE7 User's Guide
2-4 47 A2 13UR Rev00
2.1.2 Task-to-task Communication
ex "Task-to-task communication"Task-to-task communication is the same as "process-to-process" communication. In this case, both processes cooperate with each other toinsure reliable data transmission. Unlike terminal-to-process communications, both tasksacknowledge that there is an intelligent program at the other end. The DSA protocolsupported by SQL*Net enables process-to-process communication.
2.2 COR AND OPEN7
ex "OPEN7"ex "TCP/IP"ex "SQL*Net connections"COR is the ORACLE communicationsmanager (server) required by GCOS 7 to run SQL*Net. Under GCOS 7, SQL*Net canoperate if a COR is executing. SQL*Net over TCP/IP also requires OPEN7 software.
The COR communications handler must be executing in order to allow local and remoteSQL*Net connections (just as an SOR database server must be executing to allowaccess to an ORACLE database). Connections can be made from other DPS 7000s,from PCs, or from UNIX systems.
Moreover, COR must be executing on each DPS 7000 site to be used under SQL*Net.
COR generates a batch job which manages all remote connections to and from ORACLEservers/users on the site.
Additional operations required for SQL*Net over TCP/IP are described in the OPEN7Administrator's Reference Manual.
2.2.1 Enabling Remote Connections
2.2.1.1 Remote Connections Using COR I
ex "Remote connections"To enable remote connections from/to your site, enter:
COR INITIALIZE
(or, more succinctly, COR I)
COR I must be entered on each site involved before a user attempts to establish aremote connection.
2.2.1.2 Over TCP/IP
ex "SQL*Net TCP/IP server"ex "COR"ex "OPEN7"ex "TCP/IP"To enable remoteconnections over TCP/IP, the SQL*Net TCP/IP server must be started under OPEN7once COR has been started.
Architecture
47 A2 13UR Rev00 2-5
2.2.2 Disabling Remote Connections
2.2.2.1 Disabling COR
To disable remote connections from/to your site, enter:
COR SHUTDOWN
(or, more succinctly, COR S)
When COR S has been entered, new users can no longer connect from/to your site.However, the system waits for users who are already connected to disconnectthemselves.
2.2.2.2 Disabling TCP/IP
To disable remote ORACLE connections over TCP/IP disable the SQL*Net TCP/IPserver under OPEN7 prior to COR shutdown.
2.2.3 Increasing the Number of SQL*Net Connections
ex "SQL*Net connections"ex "Connections"ex "SOR"The standard SOR database serverallows up to 11 remote SQL*Net connections.
If more than 11 SQL*Net connections are needed for a given ORACLE database, anSOR ADDTASKS (or more succinctly, SOR A) command must be issued to add tasks tothe standard server.
Each time SOR A is issued the number of possible connections can be increased by 8,16, 24 or 32.
ex "TCP/IP connections"NOTE: 1. The SQL*Net communications manager(COR I command) must be started before the SOR A commandsare issued. The corresponding batch jobs terminate only when theSQL*Net Communications Manager has been disabled (COR Scommand).
2. For SQL*Net over TCP/IP the maximum number of incoming andoutgoing ORACLE connections is defined during installation andcannot be modified dynamically. Refer to OPEN7 Administrator'sGuide for SQL*Net over TCP/IP configuration.
SQL*Net V1 with ORACLE7 User's Guide
2-6 47 A2 13UR Rev00
Figure 2-2. SQL*Net Connections over DSA Error! Reference source not found.
Architecture
47 A2 13UR Rev00 2-7
Figure 2-3. SQL *Net Connections over TCP/IP Error! Reference source not found.
SQL*Net V1 with ORACLE7 User's Guide
2-8 47 A2 13UR Rev00
2.3 COMMUNICATION PROTOCOL REQUIREMENTS
ex "Communication Protocol"ex "Protocol"The SQL*Net software is designed to be easilyported to a variety of hosts. In fact, SQL*Net requires only five low level primitives thatmust be provided by the cooperating communications protocol.
To support SQL*Net, the underlying communications protocol must provide primitivesthat perform the following functions:
• Connect to remote system
• Disconnect from remote system
• Send a message
• Receive a message
• Interrupt the connection.
Architecture
47 A2 13UR Rev00 2-9
2.4 SPECIFYING A REMOTE DATABASE
ex "Remote database"This subsection presents general information on how to specify aremote database when using SQL*Net. Section 4 provides information on how to specifya remote database from a PC under MS-DOS.
Note that default values for the remote database are set during installation. Foradditional information, refer to the ORACLE Installation Guide. To indicate which local orremote database you want to interact with, you specify its name at log-on time, whetheryou are using a user-written application or an ORACLE application (such as SQL*Plus).The procedures for doing this depend on the program or interfaces involved, and aredescribed in the documentation for each program or interface. In most cases, thedatabase specification can be appended to the user/password string with an "@"character as a separator.For example, the following is a legal log-on name:
scott/tiger@D:ORA
For those programs that allow the password to be typed in separately, it may be omittedfrom the log-on name, as in:
The database specification contains information needed to direct SQL*Net to the exactdatabase to be used in the exchange. Much of the format of this specification dependson the communications protocol to be used; the specification may include routing andauthentication information as well as the node name where the database is located.
SQL*Net V1 with ORACLE7 User's Guide
2-10 47 A2 13UR Rev00
2.4.1 The Database Specification
ex "ORACLE server"ex "Protocol"ex "Asynchronous driver"ex "Driver prefix"One part ofthe specification is independent of the protocol; this is the driver prefix, which determineswhat protocol software (driver) is to be used. A database specification, therefore, can befurther refined to have the following syntax:
[driver-prefix : ] [database-id]
A distinct driver prefix is assigned to each protocol which may be used by applications onthe specified system. The set of installed protocols (and therefore the set of allowedprefixes) is determined when ORACLE is installed. The following prefixes are supportedby SQL*Net:
Table 2-2. SQL*Net Driver Prefixes Error! Reference source not found.
Prefix
A: Specifies the Asynchronous Protocol.
B: Specifies the Bull specific MS-DOS Protocols.
D: Connects to a remote system, via the DSA Protocol (theremote system is specified in the database-id). Multiplesimultaneous connections, even to the same host, areallowed.
S: Connects to the local system, using direct procedure callsin a single task (the database-id is ignored). A singleprogram may have only one active direct connection at atime.
T: Specifies the TCP/IP Protocol.
There is no default prefix.
The database-id specifies the remote system and the ORACLE database and has thefollowing syntax:
[ <rhost> : ] <sid>
<rhost> specifies the remote host system where the remote ORACLE database resides.If <rhost> is not specified a local connection will be made.
Architecture
47 A2 13UR Rev00 2-11
In a DSA network (D: prefix), <rhost> is the DSA node of the remote system and isprefixed with $.
With TCP/IP protocol (T: prefix), <rhost> is the Internet name of the remote system.
For more details about Bull MS-DOS protocol refer to Section 4.
<sid> is the identification of the remote ORACLE database. For DPS 7000, <sid> is thedirectory name under which the ORACLE server is running.
Examples:
D:ORA Local connection to ORA database.
D:$ARES:DB Remote connection to DB database on the DSA modeARES.
T:DPX231:ORA Remote connection to ORA database on the systemwhose Internet identification is DPX231.
2.4.2 The Autologon Facility
ex "Asynchronous Protocol"ex "ATLANTIS Protocol"ex "Autologon"ex "Handshakefiles"This subsection presents information that applies only when using the terminal-to-host protocols, such as the Asynchronous Protocol.
In order for communication to take place between the client and the server, the clientmust request a connection to the host. To facilitate this process, the terminal-to-processprotocols supported by SQL*Net (Asynchronous and the ATLANTIS) provide anautologon facility that automatically logs on to the remote host whenever a connection isrequested by the client system. To perform this task, autologon automatically logs on tothe remote operating system and instructs the command line interpreter to start theserver process. Thus, autologon eliminates the need for a u ser to manually log onto the remote host through a terminal emulator.
The autologon facility uses the dialogue contained within a group of "handshake files " toestablish a connection with the remote host. These handshake files are created by theuser, and contain a representation of the "conversation" that would normally take placebetween the user at the terminal and the remote host. Their contents are essentially aseries of messages that takes the form-- "send this, and expect that in return". Parametermechanisms provide for the substitution of usernames, passwords, etc.
Once the handshake files have been created, the autologon facility can be activated bysimply specifying the filename prefix that corresponds to the handshake files as part ofthe database specification string. See Section 4 for information on how to perform thesetasks.
SQL*Net V1 with ORACLE7 User's Guide
2-12 47 A2 13UR Rev00
2.5 SQL*NET RESTRICTIONS
ex "Restrictions SQL*Net"ex "SQL*Net restrictions"This subsection outlines some of therestrictions that affect the use of SQL*Net.
• Note that though an application may access several network nodes, a singletransaction or unit of work can affect only one node. For example, one SQL statementcan refer to one and only one database. However, by using the distributed querycapability provided by the ORACLE kernel, it is possible for a single SQL statement toaccess data on more than one node.
• There is no support for distributed transactions; it is possible to have multi-siteupdates, but each one would commit or rollback independently.
• Users must direct a SQL statement to the node that contains the data: there is noquery routing.
2.6 USING OTHER ORACLE UTILITIES WITH SQL*NET
ex "EXPORT"ex "IMPORT"ex "IDSORA"The use of SQL*Net with SQL*Plus, and withthe ORACLE Programmatic Interfaces, is discussed in Section 3.
In addition to these, the following ORACLE utilities can be used with SQL*Net:
• SQL*Calc
• SQL*Forms
• IMPORT
• EXPORT
• SQL*Loader
To use any of these utilities with SQL*Net, include the @ remote database clause whenlogging on.
Example:
To log on to a remote database from SQL*Plus:
SQLPLUS username/password@D:database-id
47 A2 13UR Rev00 3-1
3. Performing Database Operations
ex "Database links operation"ex "SQL*Plus"Section 3 explains how to access a remotedatabase, and how to use the SQL*Net facilities with SQL*Plus, and with the ORACLEProgrammatic Interfaces. Specific instructions for logging on to a remote database andfor performing appropriate operations are provided.
3.1 USING SQL*PLUS WITH SQL*NET
The subsections which follow introduce the distributed query facility, and describe how touse SQL*Plus with SQL*Net.
Refer the SQL*Plus documentation for further details on the use of SQL*Plus underSQL*Net.
3.1.1 Distributed Queries
ex "UPDATE command"ex "INSERT command"ex "DROP DATABASE LINKcommand"ex "DELETE command"ex "Distributed database queries"ORACLE-V5.1introduced the capability of distributed queries . A distributed query is one in whichsome or all of the queried tables are located in a database other than the one to whichyou are connected. Thus, a single query may join data from tables in multiple databases.
NOTE: that this functionality applies only to queries ; DML statements such asINSERT, UPDATE, and DELETE cannot currently be performed on multipleconcurrent databases. They may, however, be performed on a remotedatabase by using the SQL*Net facilities.
Links to remote databases are created via the command CREATE DATABASE LINK.Such links are broken via the command DROP DATABASE LINK. These and all otherSQL*Plus commands for use under SQL*Net are described in this section.
Restrictions on the use of distributed queries are given towards the end of this section.
SQL*Net V1 with ORACLE7 User's Guide
3-2 47 A2 13UR Rev00
3.1.2 Logging On To SQL*Plus Under SQL*Net from a DPS 7000
ex "Log-on"ex "SQLPLUS command"To log on to SQL*Plus, issue the followingcommand:
The database specification is described in detail in Section 2.
Examples:
SQLPLUS SCOTT/TIGER@D:$ARE2:ORA
to log on to database ORA on DSA site ARE2.
SQLPLUS SCOTT/TIGER@D:
to log on to the default local database.
SQLPLUS SCOTT/TIGER@D:ORACLE
to log on to the database ORACLE at the local site.
SQLPLUS SCOTT/TIGER@T:DPX340:W
to log on to the database W at the Internet host DPX340 over TCP/IP protocol.
Performing Database Operations
47 A2 13UR Rev00 3-3
3.1.3 The CONNECT Command
ex "CONNECT command"The CONNECT command allows you to log on to a remotedatabase (under the same name or a different name). Until CONNECT is issued, you arelogged on to the database which was specified at log-on time.
Password is the password which corresponds to username
@database-specification is a valid database specification.
Examples
CONNECT SCOTT/TIGER@D:NEWYORK-MKT
CONNECT SYSTEM/MANAGER@T:DPX230:OR
SQL*Net V1 with ORACLE7 User's Guide
3-4 47 A2 13UR Rev00
3.1.4 The COPY Command
ex "COPY command"ex "SELECT command"The COPY command is used to copy datafrom a table in one SQL*Net database to a table in another SQL*Net database. Itexecutes an arbitrary SQL SELECT command at one node, and inserts the fetched rowsinto a table at the other. You need not be directly connected to either database.
To summarize its various uses, COPY can:
• Copy data from your local database to a remote database
• Copy data from a remote database to your local database
• Copy data from one table on a remote database to another
• Copy data from a table on one remote database to a table on another remotedatabase.
The destination table may already exist, may be newly created, or it may be dropped andrecreated (replaced) prior to insertion of the data.
Note that COPY is a SQL*Plus command, and is not therefore continued automaticallyfrom line to line. (Only SQL commands are stored in the command buffer.) Use theSQL*Plus facility for continuing your input from line to line, using a dash (-).
FROM Specifies the username, password, and database where thesource table is located. The 'database-string' is a validORACLE username/password string, followed by a @,followed by a valid SQL*Net database string as shownearlier.− If FROM is omitted, the source database defaults to the
database where SQL*Plus is currently connected. In thiscase, if the SQL*Plus connection is not active, an erroroccurs.
TO Specifies the username, password, and database where thedestination table is located. The 'database-string' is a validORACLE username/password string, followed by a @,followed by a valid SQL*Net database string as shownearlier.− If TO is omitted, the destination database defaults to the
database where SQL*Plus is currently connected. In thiscase, if the SQL*Plus connection is not active, an erroroccurs.
NOTE: Since the source and destination databases cannot be the same, the FROMand TO clauses may not both be omitted.
APPEND Specifies that data must be added into the table. If the tabledoes not exist, it is created before the copied rows areinserted. If the table already exists, the copied rows areinserted into the existing table.
CREATE Specifies that the table must be created. The table is createdbefore the copied rows are inserted. If the table alreadyexists, an error occurs.
INSERT Specifies that data must be added into an existing table. Ifthe table does not exist, an error occurs.
REPLACE Specifies that data must replace (overwrite) any data whichthe table currently contains. If the table does not alreadyexist, it is created before the copied rows are inserted.
table-name Specifies a new or existing destination table (depending onthe chosen option, see above). Any valid SQL table name(including quoted or creator-qualified names) is allowed.
column-name-list Specifies the names of columns in the destination table.Any valid SQL column name (including quoted names) isallowed.A list of names must be separated by commas.− The number of columns must equal the number of
columns selected by the query (see below).− If no columns are specified, the copied columns will
have the same names in the destination table as theyhad in the source table.
SQL*Net V1 with ORACLE7 User's Guide
3-6 47 A2 13UR Rev00
USING Specifies the source table and determines which rows andcolumns will be copied from it.− The USING clause contains a SQL SELECT command
which is executed at the source node, and inserts therows it finds into a table at the destination node.
− The SELECT command is executed only at the locationspecified by the FROM clause, and can reference datafrom only one database.
− If a column-name-list is not specified with the chosenoption, the column names in the destination table aretaken from those in the SELECT list.
− The list of columns specified in the SELECT mustcorrespond one-to-one and match the columns in thedestination table.
− Refer to the SQL*Plus manuals for detailed informationon the correct SELECT command syntax.
ex "SELECT command"ex "COPY errors"ex "Error reporting"3.1.4.1 Error Reporting
Errors may be detected by the ORACLE kernel, the COPY command, or by SQL*Plus.
Standard error messages from the ORACLE kernel are prefixed by "ORA".
Error messages issued by the COPY command are listed at the end of this subsection.They are prefixed by "CPY".
Error messages detected by SQL*Plus do not have a prefix.
If a user enters an invalid SELECT clause, the segment with the error is printed in itsoriginal context, and the character which corresponds to the parse error offset is flaggedwith an asterisk.
In general, the kernel detects errors in the SQL statements that COPY generates. COPYdetects errors in the arguments it receives via the programmatic interface, and SQL*Plusdetects errors in the syntax of the COPY command itself.
Error messages with the prefix "CPY" may be returned by COPY via SQL*Plus. Here is alist of COPY errors along with possible causes and suggested actions.
Performing Database Operations
47 A2 13UR Rev00 3-7
CPY0002 Illegal or missing APPEND, CREATE, INSERT, or REPLACE option
Cause : Internal error: parameter value out of range. SQL*Plus hasinvoked COPY with a create option value that is out ofrange. This error should not normally occur.
Action : SQL*Plus internal error: please contact your CustomerSupport representative.
CPY0003 Internal error: logical host number out of range
Cause : Internal error: parameter value out of range. An internalCOPY function has been invoked with a logical host numbervalue that is out of range. This error should not normallyoccur.
Action : COPY internal error: please contact your Customer Supportrepresentative.
CPY0004 Source and destination table column names don't match
Cause : SQL*Plus user error. On an APPEND-table operation, or anINSERT (when the table exists), at least one column name inthe destination table is not the same as the correspondingcolumn name in the optional column name list or in theSELECT command.
Action : Re-enter the COPY command, making sure that the columnnames and their order in the destination table are the sameas their names and order in the optional column list or in theSELECT command.
CPY0005 Source and destination column attributes don't match
Cause : SQL*Plus user error. On an APPEND-table operation, or anINSERT (when the table exists), at least one column in thedestination table is not the same data type (NUMBER,CHAR, DATE, etc) as the corresponding column in theSELECT command.
Action : Re-enter the COPY command, making sure that the datatypes for items being selected agree with the destination.You can use the TO_DATE, TO_CHAR, and TO_NUMBERfunctions to make conversions, as necessary.
CPY0006 Select list has more columns than destination table
Cause : SQL*Plus user error. On an APPEND-table operation, or anINSERT (when the table exists), the number of columns inthe SELECT command is greater than the number ofcolumns in the destination table.
Action : Re-enter the COPY command, making sure that the numberof columns being selected agrees with the number in thedestination table.
SQL*Net V1 with ORACLE7 User's Guide
3-8 47 A2 13UR Rev00
CPY0007 Select list has fewer columns than destination table
Cause : SQL*Plus user error. On an APPEND-table operation, or anINSERT (when the table exists), the number of columns inthe SELECT command is less than the number of columnsin the destination table.
Action : Re-enter the COPY command, making sure that the numberof columns being selected agrees with the number in thedestination table.
CPY0008 More column list names than columns in destination table
Cause : SQL*Plus user error. On an APPEND-table operation, or anINSERT (when the table exists), the number of columns inthe column name list exceeds the number of columns in thedestination table.
Action : Re-enter the COPY command, making sure that the numberof columns in the column name list agrees with the numberin the destination table.
CPY0009 Fewer column list names than columns in destination table
Cause : SQL*Plus user error. On an APPEND-table operation, or anINSERT (when the table exists), the number of columns inthe destination table exceeds the number of columns in thecolumn name list.
Action : Re-enter the COPY command, making sure that the numberof columns in the column name list agrees with the numberin the destination table.
3.1.4.2 COPY Examples
ex "COPY examples"The following examples illustrate various ways of using the COPYcommand.
COPY FROM joe/blow@d:BOSTON-mkt - TO scott/tiger@d:BOSTON-mfg - CREATE managers - USING SELECT ENAME,JOB,SAL - FROM EMP - WHERE JOB IN ('MANAGER', 'PRESIDENT')
COPY FROM moe/joe@d:NEWYORK-mkt - TO scott/tiger@CHICAGO-mkt - REPLACE dept (department, name, location, empcount) USING SELECT EMP.DEPTNO, - DNAME, - LOC, - COUNT(*) - FROM EMP,DEPT - WHERE EMP.DEPTNO = DEPT.DEPTNO - GROUP BY EMP.DEPTNO, DNAME, LOC
Performing Database Operations
47 A2 13UR Rev00 3-9
COPY FROM scott/tiger@d:DENVER-qa - CREATE Mr_King - USING SELECT * - FROM EMP - WHERE ENAME = 'KING'
COPY TO scott/tiger@d:DEVVMS - INSERT tablelist ("Table Name", creator) - USING SELECT TNAME, CREATOR - FROM SYSCATALOG
COPY FROM scott/tiger@d:ERNIE-sys8 - TO system/manager@d:BERT-qa - REPLACE "Monthly Wages Paid" (total) - USING SELECT SUM(SAL)+SUM(NVL(COMM,0)) - FROM EMP
COPY FROM JOE/FOO@D:GREEN-x - TO SCOTT/TIGER@D:YELLOW-y - APPEND EMP - USING SELECT * - FROM EMP
COPY FROM scott/tiger@T:DPX2:W - CREATE MYTAB - USING SELECT * FROM HISTAB
3.1.4.3 Macro Substitution
ex "COPY macro substitution"ex "Macro substitution"The SQL*Plus macro substitutionoperators, "&&" and "&", may be used within the COPY command line, as long as thesubstituted elements form a syntactically correct command.
Note that the SQL*Plus continuation character, "-", is supported.
For example, the following interactive session copies all employee names from EMP toNEWEMP at "SCOTT/TIGER@D:ORA" :
SQL> COPY FROM &&s TO &s -> CREATE &t -> USING &sel
Enter value for s: SCOTT/TIGER@D:ORAEnter value for t: NEWEMPEnter value for sel: SELECT ENAME FROM EMP
3.1.4.4 Effect on Open Transactions in SQL*Plus
The COPY command always commits rows inserted into the destination table. Inaddition, the COPY command commits any transaction that was not closed (committedor rolled back) in SQL*Plus prior to invocation of the COPY command, if the destinationtable is located at the SQL*Plus default connection (that is, if the "FROM" or "TO" clauseis missing).
SQL*Net V1 with ORACLE7 User's Guide
3-10 47 A2 13UR Rev00
3.1.4.5 Internals
ex "ARRAYSIZE"ex "COPY internals"ex "COPY COMMIT option"ex "LONG option"ex"MAXDATA"ex "SET"The COPY command has parameters for specifying the array fetchsize, the buffer length for LONG columns, and the frequency of commits. COPY uses theSQL*Plus "SET" options ARRAYSIZE, LONG, and COPYCOMMIT, respectively, tospecify these parameter values. These options may be assigned and examined by theSQL*Plus SET and SHOW commands.
ARRAYSIZE (1-5000, default 20). This option controls the size of the arraythat is used for fetching rows. The value of ARRAYSIZE isthe number of rows that may be fetched at one time by asingle request to the ORACLE kernel. This value is used bythe COPY command as well as by other SQL*Pluscommands. The COPY command administers its memorymanagement independent of SQL*Plus; consequently, it ispossible for an ARRAYSIZE setting to be "too large" for theMAXDATA parameter initially allocated by SQL*Plus, butvalid for use by the COPY command.
LONG (1-32767, default 80). This option determines the maximumlength of a LONG column that may be retrieved from a table.This value is used by the other SQL*Plus commands as wellas the COPY command.
COPYCOMMIT (0-5000, default 0). This option determines the frequency ofthe destination table commits. A non-zero value n instructsthe system to commit after every n groups of rows areinserted, where the group size is controlled by ARRAYSIZE;and to commit when finished. A value of zero instructs thesystem to commit when done, only after all rows have beeninserted.− For example, if ARRAYSIZE is 50 and COPYCOMMIT
is 4, commit will be performed after every 200 rows areinserted; that is, after row 200, 400, 600, etc , and afterthe last row.
Performing Database Operations
47 A2 13UR Rev00 3-11
3.1.5 Database Links
ex "Remote database"ex "Local database"ex "Database links"ex "CREATE DATABASELINK"ex "DROP DATABASE LINK"ex "Private links"ex "Public links"When you startSQL*Plus, it normally connects to an ORACLE database on your host computer. InSQL*Net terms, this database is called the local database .
When you use a database on another computer via SQL*Net, that database is called aremote database .
To use a table in a remote database, SQL*Plus must know:
• Which database you wish to use
• Which user's tables you wish to access in that database
You can do both of these things by creating a database link .
A database link is a named object stored in the local database. Each link identifies:
• A remote database
• A username on the remote database
• The password for that username.
You identify a remote database by its database specification as described in Section 2.
Once a database link has been created, you can use it to query tables on a remotedatabase (in exactly the same way as you would do so on your local database).
A database link can be:
• For use by one user only (private database links)
• For use by all users (PUBLIC database links) .
Database links are created and removed by means of two special SQL commands:
• CREATE DATABASE LINK to create a link
• DROP DATABASE LINK to remove a link.
These two commands are described below.
SQL*Net V1 with ORACLE7 User's Guide
3-12 47 A2 13UR Rev00
3.1.5.1 The CREATE DATABASE LINK Command
ex "CREATE DATABASE LINK command"The CREATE DATABASE LINK command isused to create a link (or path) from a local database to a username on a remotedatabase.
The link is stored in the local database for use by one user, or by all users (a PUBLICdatabase).
Once a database link has been established, you can query a table on the remotedatabase associated with the link by referring to the link in the FROM clause of a queryor subquery. The query or subquery behaves as if you were connected directly to theremote database as a valid user.
Syntax
CREATE [ PUBLIC ] DATABASE LINK <link-name>
CONNECT TO <username>
IDENTIFIED BY <password>
USING '<SQL*Net-connection-string>'
Parameter Descriptions
PUBLIC If PUBLIC is specified, the link is available to all users(except those who have created a private database link withthe same name). Only DBAs can use the PUBLIC option.− If PUBLIC is omitted, the link is available only to its
creator; that is, the associated username/passwordcombination. This is sometimes known as a private link.
link-name This is the name by which the link is known. It is used toqualify object names in queries such that SQL*Plus knowsautomatically which remote database you wish to access.
username This is the ORACLE username which is used to log on to theremote database. It must be a valid name on the specifiedremote database. This name need not be the same as thelocal database username.
password This is the password which corresponds to the ORACLEusername on the remote database.
Performing Database Operations
47 A2 13UR Rev00 3-13
SQL*Net-connection-string
• This is the string which specifies the driver prefix, node, and database name where theconnection is to be made.
• The string must be enclosed in single (') quotes.
• The syntax corresponds to the database specification syntax which was described inSection 2.
NOTE: When PUBLIC database links are created, it is good practice to specify astandard username which exists only for the purpose of linking to the remotedatabase. (Refer to the second example overleaf). Such a standard usernameshould not 'own' any tables on the remote database. Thus, table owners on theremote database can decide which table(s) are to be accessible to remoteusers by granting the correct access rights. (See the GRANT command in theSQL*Plus documentation.) Any tables for which permissions are not granted tothe standard username will not be accessible. This provides a good level ofsecurity.
Queries and subqueries performed through database links are subject to certainrestrictions:
• The number of database links that can be used in a single command is limited initiallyto four. This can be changed by the DBA, (see the OPEN_LINKS parameter in theDatabase Administrator's Guide).
• Long columns cannot be selected by a query through a database link.
• In tree-structured queries (using the CONNECT BY clause):
− the PRIOR operator cannot be used in clauses other than CONNECT BY,
− the START WITH clause cannot contain subqueries,
− neither the CONNECT BY nor the START WITH clauses can contain the functionUSERENV('ENTRYID'), user-defined functions, or ROWNUM.
SQL*Net V1 with ORACLE7 User's Guide
3-14 47 A2 13UR Rev00
Examples
ex "CREATE DATABASE LINK command examples"SQL> CREATE DATABASE LINKBOSTON 2 CONNECT TO SCOTT 3 IDENTIFIED BY TIGER USING 'D:ORA';
The above example creates a private database link called BOSTON. It links a usernamed SCOTT, with password TIGER, to a database which is identified by thespecification D:ORA. D: is the communications driver prefix (see Section 2), and ORA isthe ORACLE database. Since no specific node is given, this database is at the local site.
SQL> CREATE PUBLIC DATABASE LINK KINGSTON 2 CONNECT TO NETWORK 3 IDENTIFIED BY NETPASS 4 USING 'D:$ARE2:ORACLE';
The above example creates a public database link called KINGSTON. It links a usernamed NETWORK, with password NETPASS, to a database called ORACLE at DSA siteARE2.
Notice the username NETWORK. The notes on the previous page described how astandard username can be set up for public links. Here, NETWORK is used to do this. Itdoes not own any tables in the KINGSTON database; but table owners in the KINGSTONdatabase can decide which tables are accessible to the NETWORK/NETPASScombination. They can also deny access by remote users to tables containing sensitiveinformation.
SQL> CREATE DATABASE LINK SLOUGH 2> CONNECT TO JOHN 3> IDENTIFIED BY JNS 4> USING 'B:SYN7:\ORACLE5\NET\LOG7:PASC.ORA51';
The above example shows how to create a link from a PC to a DPS 7000 using the Bull-specific B: protocol.
If you wanted to pass parameter values with the connection, say, SMITH and SMT, youwould replace line 4> above by, for example:
4> USING 'B:SYN7:\ORACLE5\NET\LOG7B,SMITH,SMT:PASC.ORA51';
To access the EMP table via the SLOUGH link, enter:
SQL> SELECT * FROM EMP@SLOUGH;
Performing Database Operations
47 A2 13UR Rev00 3-15
3.1.5.2 The DROP DATABASE LINK Command
ex "DROP DATABASE LINK command"ex "DROP DATABASE LINK commandexamples"The DROP DATABASE LINK command is used to remove an existingdatabase link, and commit any pending changes to the remote database.
Syntax
DROP [PUBLIC] DATABASE LINK <link-name>
Parameter Descriptions
PUBLIC If the link is public, the PUBLIC option must be specified.
Only DBAs can use the PUBLIC option.
If the link is private, the PUBLIC option is omitted
link-name This is the name by which the link is known.
Examples
SQL> DROP DATABASE LINK BOSTON;
The above example removes a private database link called BOSTON.
SQL> DROP PUBLIC DATABASE LINK KINGSTON;
The above example removes a public database link called KINGSTON.
3.1.6 Querying Remote Tables
ex "CREATE DATABASE LINK command"ex "SELECT command"ex "Remote tables"ex"Remote table queries"Once you have created a private database link, (or know thename of a valid public database link), you can use the link to perform queries on remotetables.
@link-name specifies the link. If a link is entered and a userid is not entered, the querylooks for a table owned by the user specified in the database link definition (that is, theCONNECT TO clause of the CREATE DATABASE LINK command).
You can also query tables belonging to other users (as long as they have grantedSELECT access rights to the username specified in the database link - see the GRANTcommand in the SQL*Plus documentation).
SQL*Net V1 with ORACLE7 User's Guide
3-16 47 A2 13UR Rev00
A simple example:
SQL> SELECT EMPNO, ENAME, DEPTNO
2 FROM EMP@BOSTON;
The above example performs a simple query on the table EMP. The table EMP is ownedby the user specified in the link called BOSTON.
The FROM clause specifies the table EMP at (@) the database link BOSTON.
You can use a database link in the FROM clause of almost any query.
The example below performs a query to join the table EMP on your own database withthe table DEPT at BOSTON:
SQL> SELECT DEPT.DEPTNO, DNAME, LOC, ENAME, JOB 2 FROM EMP, DEPT@BOSTON 3 WHERE EMP.DEPTNO = DEPT.DEPTNO 4 AND EMP.DEPTNO IN (30,40) 5 ORDER BY EMP.DEPTNO;
The example below shows how to query a table on a remote database, which is ownedby user ADAMS:
SQL> SELECT* 2 FROM ADAMS.EMP@BOSTON;
This query selects all rows from the table EMP, owned by ADAMS, at database linkBOSTON.
3.1.7 Creating Synonyms for Remote Tables
ex "Synonyms"ex "CREATE SYNONYM command"ex "Remote table synonyms"ex"Remote table views"You can create synonyms for remote tables or views. In this wayyou can specify the synonym instead of the database link when accessing the table orview.
Example:
SQL> CREATE SYNONYM BOSTON_EMP 2 FOR EMP@BOSTON;
This example defines a synonym for the table EMP at BOSTON. You could now performa query on EMP by specifying BOSTON_EMP in the FROM clause.
Performing Database Operations
47 A2 13UR Rev00 3-17
3.1.8 Creating Views for Remote Tables
ex "CREATE VIEW command"ex "DELETE command"ex "Views"You can create viewsto refer to remote tables.
Example:
SQL> CREATE VIEW BOSTON_VIEW 2 AS SELECT * 3 FROM EMP@BOSTON;
This example defines a view for the table EMP at BOSTON. You could now perform aquery on EMP by specifying BOSTON_VIEW in the FROM clause.
3.1.9 Deleting from a Remote Table
ex "Remote table deletions"You can delete information from a remote table by using theDELETE command. You must be connected to the remote database.
Example:
SQL> CONNECT SCOTT/TIGER@D:BOSTONSQL> DELETE 2 FROM EMP 3 WHERE DEPTNO = 50;
This example deletes all rows from the table EMP at D:BOSTON where the DEPTNOattribute equals 50.
3.1.10 Inserting into a Remote Table
ex "INSERT command"ex "Remote table insertions"You can insert information into aremote table by using the INSERT command, but you must be connected to theremote database.
Examples:
The first example inserts a new row into the table EMP at D:BOSTON.
The second example inserts one or more rows into the table BONUS (at BOSTON),depending on how many valid rows are selected from the table EMP at KINGSTON.
SQL> INSERT INTO BONUS 2 SELECT ENAME, JOB, SAL, COMM 3 FROM EMP@KINGSTON 4 WHERE COMM > .25 * SAL 5 OR JOB IN ('PRESIDENT', 'MANAGER');
SQL*Net V1 with ORACLE7 User's Guide
3-18 47 A2 13UR Rev00
Performing Database Operations
47 A2 13UR Rev00 3-19
3.1.11 Copying from a Remote Node to a Local Node
You can copy data from a remote node to a local node using the following syntax:
SQL> INSERT INTO table_here 2 SELECT * FROM table_there@dblink
3.1.12 Restrictions on Database Object Names
ex "Names"ex "Restrictions database object names"ex "Restrictions distributedqueries"The use of the commercial at (@) sign for names of database objects such astables, views, and space definitions must be avoided.
Any current applications which use object names containing the at sign must either bechanged, or all object names containing this character must be enclosed in doublequotes (").
Database object names:
• Must begin with a letter
• Can include alphabetic or numeric characters
• Can include the hash (#) symbol,the underscore (_) character,and the dollar ($) sign,
• Should not include the commercial at (@) sign.
3.1.13 Restrictions on Distributed Queries
ex "CONNECT BY clause"ex "CREATE SYNONYM command"ex "UPDATEcommand"ex "CREATE TABLE command"ex "CREATE VIEW command"ex "LONGdata type"ex "Nested queries"ex "PRIOR operator"ex "ROWNUM"ex "SELECTcommand"The following are current restrictions on distributed processing:
• Remote tables can be referenced only in the following ways:
− Queries (SQL commands beginning with SELECT)
− Nested SELECT commands used with INSERT, UPDATE, CREATE TABLE, orCREATE VIEW
− CREATE SYNONYM
• You cannot select columns of type LONG from remote tables.
SQL*Net V1 with ORACLE7 User's Guide
3-20 47 A2 13UR Rev00
• Queries using the CONNECT BY clause have some restrictions:
− The use of the PRIOR operator on columns in clauses other than CONNECT BYwill produce incorrect results. That is, the column(s) will have a value of NULLinstead of the correct value.
− The START WITH clause cannot contain subqueries.
− The START WITH clause and the CONNECT BY clause cannot contain theUSERENV('ENTRYID') function, user-defined functions, or ROWNUM.
• You cannot INSERT into, UPDATE, or DELETE from any data from remote tablesunless you are logged on directly to the remote database.
3.1.14 Links are Stored in the Data Dictionary
ex "SYS.DBLINKS view"ex "Dictionary views"A dictionary view is available whichprovides information about the various database links in the system. It is calledSYS.DBLINKS, and is accessible only by DBAs.
SYS.DBLINKS shows the owner, name, host username, and remoteusername for all database links in the system. This view canbe accessed only by DBAs.
The DBA, or a user with DBA access rights, can access this view in standard SQLqueries.
Examples:
SQL> DESCRIBE SYS.DBLINKS;
This shows you the name and type of each attribute in SYS.DBLINKS.
SQL> SELECT * 2 FROM SYS.DBLINKS;
This selects all the rows from the SYS.DBLINKS view.
Performing Database Operations
47 A2 13UR Rev00 3-21
3.2 USING THE ORACLE PROGRAMMATIC INTERFACES WITH SQL*NET
ex "Programmatic interfaces"This subsection describes how SQL*Net can be used toaccess a remote database from a pre-compiled program. All other aspects of the Proseries pre-compilers are dealt with in the documentation for each specific product.
The ORACLE Programmatic Interfaces support access to other machines, and todatabases on those machines, via the SQL*Net facilities.
Firstly, a connection must be established with the remote database. Study the syntaxbelow:
EXEC SQL CONNECT :username IDENTIFIED BY :password AT identifier USING :db-specification
where:
username Is a valid username on the remote database
password Is the password which applies to the username
identifier Is a name used to identify the connectionIt is not a host variable
db-specification Is described in detail in Section 2.
Example:
ex "EXEC SQL"EXEC SQL CONNECT :UID IDENTIFIED BY :PWD AT ORA7 USING :HST
If the host variables UID, PWD, and HST respectively contain the strings "SCOTT","TIGER", and "D:$ARE2:ORA", then this connects the pre-compiled program to thedatabase ORA on site ARE2 under the remote username SCOTT whose remotepassword is TIGER. This database connection is identified by the name ORA7.
Once a connection (such as the one shown on the previous page) has been established,other EXEC SQL statements use the AT clause to tell the pre-compiler where to issuethe call. You must use the AT clause if you are using neither a declare statement, nor acursor.
Example:
EXEC SQL AT ORA7 CREATE TABLE T (X NUMBER)
In the above example, a table T is created at ORA7.
However, when using cursors, you specify the AT clause only when you declare thecursor. It is not necessary to do this for subsequent manipulations.
SQL*Net V1 with ORACLE7 User's Guide
3-22 47 A2 13UR Rev00
Example:
EXEC SQL AT ORA7 DECLARE C1 CURSOR FOR SELECT ENAME FROM EMP
...
EXEC SQL OPEN C1
and not,
EXEC SQL AT ORA7 OPEN C1
The same is true with statements. You need to specify the AT clause only at declarationtime.
With SQL*Net, you can write programs which handle several databases simultaneously;but you can update only one database within the same commitment unit.
Performing Database Operations
47 A2 13UR Rev00 3-23
47 A2 13UR Rev00 4-1
4. SQL*Net on a PC Under MS-DOS(synchronous and asynchronous protocols)
ex "ALX"ex "MSDOS"ex "PC installation of SQL*Net"ex "SQL*Net PCs"SQL*Net allowsyou to log on to a remote ORACLE database from a PC running under MS-DOS.
This section deals with the following points:
• Installing SQL*Net on the PC:
− installing the drivers
− loading the drivers
− setting up various log-on procedures.
It is assumed that the reader is able to use the MS-DOS operating system, and thathe/she has access to the necessary manuals. MS-DOS is discussed here only as itaffects the installation and use of SQL*Net on a PC.
Users who have synchronous communication lines will need an ATLANTIS card. Forinformation concerning ATLANTIS, refer to the specific ATLANTIS documentation.
ex "PC Asynchronous device driver"SQL*Net requires five executable MS-DOS files tobe installed. These files are delivered with GCOS 7 ORACLE.
Once the correct installation of GCOS 7 ORACLE has taken place on the mainframe, thefive files are contained in the .BIN library under the following names:
[Note that, if manual installation of GCOS 7 ORACLE was carried out, the five files listedabove might be in a different BIN type library. If in doubt, refer to the ORACLE7Installation Guide.]
The above five files must be copied from the GCOS 7 BIN library to the PC. You can useMICROFIT7 to do this. Alternatively, your system administrator may be able to supplyyou with a diskette.
Under MS-DOS, the five files are named as follows:
Copy them under the directory NET. On most PCs, this is \ORACLE\NET
SQLNET7.COM (asynchronous) and SQL6003.COM (synchronous) contains theSQL*Net executable code.SQLNET7.PXE is needed only if you are using your PC in "professional mode", that is,there is a local ORACLE database, and you can create database links.
D_ASY7.BIN device driver is required only if your communication line isasynchronous .
D_SYN7.BIN device driver is required only if your communication line is synchronous ,and if you have an ATLANTIS card.
If your line is synchronous, you need the transport software associated with theATLANTIS card you are using.
Synchronous lines must have a correctly installed configuration file. Refer to theATLANTIS documentation to install and configure the telecommunication hardware.Alternatively, ask your network administrator.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-3
4.1.1 Installing the Asynchronous device Driver
ex "Asynchronous device driver"ex "Baud rate"ex "DEVICE"The asynchronous devicedriver is called D_ASY7.BIN.
D_ASY7.BIN must be declared in the \CONFIG.SYS file of the MS-DOS system, asfollows:
DEVICE = <path> \D_ASY7.BIN [ parameters ]
Description:
<path> is the directory under which the D_ASY7.BIN module hasbeen installed. This is usually \ORACLE\NET , but thedirectory can take any valid name.
parameters Offers a series of options which define the port name, parity-type, and so on. They are listed below:
/Cn Specifies the port address. n identifies the port COMn wherethe asynchronous board is connected. n can take the values1 or 2; 1 is the default. The default is generally correct, butthis depends on the PC configuration.
/In Specifies the hardware interrupt to be used. n can take thevalues 3 or 4; 4 is the default. The default is generallycorrect, but this depends on the PC configuration.
/Vn Specifies the baud rate (or line speed). n can take thefollowing values:
0 for a 75 baud line 1 for a 150 baud line 2 for a 300 baud line 3 for a 600 baud line 4 for a 1200 baud line 5 for a 2400 baud line 6 for a 4800 baud line 7 for a 9600 baud line 8 for a 19200 baud line (please check availability with your Customer Service Center).
The default is 7.
SQL*Net V1 with ORACLE7 User's Guide
4-4 47 A2 13UR Rev00
/Pn Specifies the parity-type of the line.n can take the following values:
0 for no parity 1 for EVEN parity 2 for ODD parity
The default is 1.
/Nn Specifies the number of bits.n can take the values 7 or 8; 7 is the default.
/Sn Specifies the number of stop-bits.n can take the values 1 or 2; 1 is the default.
Example:
DEVICE = \SQLNET7\D_ASY7.BIN /V4 /P2
The above example declares a 1200 baud line speed, with ODD parity-type.The other parameters take the default values.
To install the D_ASY7 driver on a PC, you must:
• Copy it under a directory of your choice
• Add the <DEVICE => syntax to the \CONFIG.SYS file, by using EDLIN, for example.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-5
4.1.2 Installing the Synchronous device Driver
ex "Synchronous device driver"ex "Baud rate"ex "PC CONFIG"ex "PC Synchronousdevice driver"The synchronous device driver is called D_SYN7.BIN .
D_SYN7.BIN must be declared in the \CONFIG.SYS file of the MS-DOS system, asfollows:
DEVICE = <path> \D_SYN7.BIN /Ann [ /Vn ]
Description:
<path> Is the directory under which the D_SYN7.BIN module hasbeen installed. This is usually \ORACLE\NET , but thedirectory can take any valid name.
/Ann Specifies the station address. There is no default. You mustgive the same value as shown on the ATLANTIS terminalemulator configuration form.
/Vn Specifies the baud rate (or line speed). n can take thefollowing values:
4 for a 1200 baud line 5 for a 2400 baud line 6 for a 4800 baud line 7 for a 9600 baud line
The default is 7.
Example:
DEVICE = \ORACLE\NET\D_SYN7.BIN /A01
The above example declares a 9600 baud line speed (by default). The driver has beeninstalled in the \ORACLE\NET directory, and the address of the station is 01.
To install the D_SYN7 driver on a PC, you must:
• Copy it under a directory of your choice
• Add the <DEVICE => syntax to the \CONFIG.SYS file, by using EDLIN, for example
• Install and configure the transport ATLANTIS software.
SQL*Net V1 with ORACLE7 User's Guide
4-6 47 A2 13UR Rev00
4.1.3 CONFIG Parameters
ex "CONFIG"You can customize your SQL*Net configuration by changing the values ofthe CONFIG parameters which are defined in the ORACLE CONFIG file, (usually named\ORACLE\CONFIG.ORA).
The following line can be added:
CTX_NET7=<value>
Where <value> takes the form xxxx (four hexadecimal digits).This hexadecimal value determines the number of bytes of RAM which the SQLNET7 orSQL6003 driver will use for buffers and other types of data storage.The default is 4000 (hexa).The following line can also be added:
B_NET7=<value>
Where <value> is four hexadecimal digits, as above.This hexadecimal value determines the number of bytes the SQLNET7 or SQL6003driver will use for data communication. The default is 0200 (hexa).The maximum size of a packet transmitted is:
(B_NET7+16) * 2
(hexadecimal)(including header and SQLNET7 or SQL6003 protocol conversion).
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-7
4.2 LOADING THE SQL*NET DRIVERS
ex "SQL*Net driver code"Once the SQL*Net drivers have been installed on the PC, theymust be loaded into memory before they can be used by the ORACLE code.
To load the SQL*Net drivers into memory, you must type the following command (underthe directory where the code has been installed):
C> SQLNET7 (for asynchronous communication line) orC> SQL6003 (for synchronous communication line)
If you use a local ORACLE database on your PC, you must load the ORACLE kernelcode first (ORACLE command), and then load the SQL*Net drivers (SQLNET7 orSQL6003 command):
C> ORACLEC> SQLNET7 (for asynchronous communication line) orC> SQL6003 (for synchronous communication line)
This is because the SQLNET7 or SQL6003 driver loads the SQLNET7.PXE code only ifthe ORACLE code has already been loaded.To make use of database links, the SQLNET7.PXE code must be loaded.SQLNET7.PXE must be present in the current directory when you type the SQLNET7 orSQL6003 command.
You can perform an automatic load by adding three lines to the ORACLE.BAT file, asfollows:
CD \ORACLE\ NETC> SQLNET7 (for asynchronous communication line) orC> SQL6003 (for synchronous communication line)
If you do this, you can type the name of the batch file once each time you start (or re-boot) the PC, and the SQL*Net drivers are loaded automatically.
[Alternatively, you could create a small batch file containing the above lines of code, andexecute that file separately instead.]
Once the SQL*Net drivers have been loaded into memory, you can:
• Use ORACLE processors with local connections to database servers
• Use ORACLE processors with remote connections to database servers
• Access data through database links (described in earlier sections).
SQL*Net V1 with ORACLE7 User's Guide
4-8 47 A2 13UR Rev00
4.3 LOG-ON PROCEDURES
ex "Log-on"ex "PC autologon"ex "PC manual log-on"Log-on from a PC can be performedeither manually, or automatically
An autologon dialog description (sometimes known as "handshake file s") can be set upand stored, ready for automatic execution at log-on time. If a problem occurs duringautologon, the system reverts to a manual log-on.
Autologon procedures can be made very concise by means of:
• Macros
• Specification of default databases.
The autologon phase can be traced in the LOG7.TRC trace file.
All the above topics are covered in the following pages.
4.3.1 Manual Log-on
ex "Manual log-on"ex "PC driver"A manual log-on capability is provided if necessary.This can be useful for debugging any problems with the network connection.
If you are using autologon procedures, and a problem occurs, the system switchesautomatically to manual mode. To work in manual mode, you can specify an invaliddialog description (see the network-path parameter below).
To connect to an ORACLE server on a DPS 7000 from a PC, you must use the followingsyntax:
@B Is the driver prefix. B is the BULL-specific MS-DOS protocols.
driver Is the protocol to be used, depending on the communicationsline.Possible values are ASY7 (for asynchronous lines), or SYN7(for synchronous lines).There is no default value.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-9
identification Is used only for X25 Transpac connection. It takes the form: <prefix><number>prefix always takes the value "C".number is the Transpac subscription number of the targetsite.
network-path Specifies an autologon dialog description (or "handshakefile") which is used to connect automatically to the DPS7000. Enter a "conventional invalid value" such as a zero (0)character to work in manual mode (see above).
directory Specifies the name of the database on the DPS 7000 whereyou wish to connect. This name is the directory under whichthe SOR database server is executing on the targetdatabase.
ex "transpac"Example:
C> SQLPLUS SCOTT/TIGER@B:SYN7,C178190734:0:ORA
In the above example, the SQL*Plus processor is called, with a username/passwordcombination of SCOTT/TIGER. A synchronous line is declared (SYN7), and databaseORA is specified. 0 is entered to perform connection in manual mode. An X25subscription number is used for connection to Transpac. It is 178190734.
NOTE: that the site where the ORACLE server is executing is not specified here. Thesite is given during manual connection to the DPS 7000 (described overleaf).
4.3.1.1 Once the SQL*Plus Processor has been Called
The SQL*Net driver asks you to connect to the target site.
You must type the following:
$*$LC ON
If you are using the asynchronous (ASY7) driver, you must also type:
$*$DCLIST:$*$LC OFF
Then you can connect to the DPS 7000 in the standard way. For example:
$*$CN -MB ORACLE -SC ARE2 -USR JONES -PW JNS
Here, the connection is made to the ORACLE mailbox on site ARE2. The user isJONES, and the password is JNS. Note that the ORACLE mailbox is always calledORACLE to simplify connection.
SQL*Net V1 with ORACLE7 User's Guide
4-10 47 A2 13UR Rev00
4.3.1.2 As Soon as Connection is Made
ex "COR"Type F1 to return control to the processor (here, SQL*Plus) which called theSQL*Net driver.
NOTE: The connection may be rejected. Possible reasons are:
− The Communications Manager (COR) has not been started on the specifiedsite so that the ORACLE mailbox is unknown.
Action: start COR on the site in question.
− The specified site is currently inaccessible. This is due to some networkproblem.
− The required database server on the target database is not ready.
Action: start the ORACLE server on the target database.
4.3.1.3 When Connected to ORACLE Server on PC
You can use ORACLE as if the database on the DPS 7000 were on your own PC.
4.3.1.4 Disconnection
When you wish to leave the current processor, the SQL*Net driver requests you todisconnect manually from the ORACLE mailbox.
At this point, you can:
• Type $*$DIS to disconnect the session, and then F1 to return
• Or, type F1 directly. This retains the ORACLE connection for the next time so that youcan simply type F1 again to reconnect. Not all ATLANTIS boards have this facility,however, and the session may be lost in some cases.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-11
4.3.2 Autologon
ex "Autologon"ex "Dialog descriptions"ex "PC autologon"An autologon capability isavailable to enable you to connect dynamically to ORACLE servers on DPS 7000mainframes without needing to issue any network connection dialog.
To make use of autologon, you must create a description of the dialog which takes placewhen connecting your PC to a DPS 7000 site in the network. Such descriptions arecalled dialog d escript ions . They are contained in autologon files (sometimes called"handshake files").
You can also use macros and parameters to reduce the number of files which arenecessary.
NOTE: Autologon does not support dial-up connections from a PC to a host DPS 7000.
The name of the autologon file to be used and the parameters to be used with it arespecified as follows:
@B Is the driver prefix. B is the BULL-specific MS-DOSprotocols.
driver Is the protocol to be used. Possible values are ASY7 (forasynchronous lines), or SYN7 (for synchronous lines).There is no default value.
id Is used only for X25 Transpac connection. It takes the form: <prefix><number>Prefix always takes the value "C".number is the Transpac subscription number of the targetsite.
file-path-name Specifies the full path name of the autologon file whichcontains the necessary dialog description. The syntax for thedialog description has its own subsection further on in thisguide.The default value is \ORACLE5\NET\LOG7.
par1...par9 Are the values to be used for between one and nine parameters. [They arereferred to during the connection phase as #1, #2 and so on.] Each parameter must bepreceded by a comma (,).
dir Specifies the name of the database on the DPS 7000 where you wish to connect.This name is the directory under which the SOR database server is executing on thetarget database.
In the above example, the SQL*Plus processor is called, with a username/passwordcombination of SCOTT/TIGER. A synchronous line is declared (SYN7), and databaseORA is specified. The autologon file to be used is \MYLOG. Two parameter values aregiven: ARE2, the target site; and MYPWD, the password.
Once the processor (in our example, SQL*Plus) has been called, the SQL*Net driverautomatically connects you to the DPS 7000, using the autologon file specified by\MYLOG which contains, for example:
(CN -MB ORACLE -SC #1 -USR JONES -PW #2 *$$*CONNECTED)::(^)
The connection is made to the ORACLE mailbox on ARE2 (the value of #1). The user isJONES, and the password is JNS (the value of #2).
This is an autologon dialog description. This is described further on. Here, the syntaxexpects that the connection will be successful; if not, the connection fails, and theSQL*Net driver returns control to the calling processor (in our case, SQL*Plus).
Model types
In synchronous mode, you can use the following model types:
DKU 7107DKU 7211VIP 7804
In asynchronous mode, you can use the following model types:
TTU 8124VIP 7800PC 7804
4.3.3 Autologon Dialog Description
ex "PC autologon dialog description"Autologon files contain a series of instruction lines,each of which takes the following form:
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-13
4.3.3.1 The instruction line
( ) Parentheses must enclose each interaction, that is, the<send_string> and the <receive_string> together.
send_string Is a character string sent by the SQL*Net driver. It simulatesthe action of a user who wants to initiate a connection.In other words, it is the input of one interaction.
? Is the separator between the send_string and thereceive_string.
receive_string Is a character string which must be matched by a returningmessage. If matched, the interaction has succeeded.In other words, it is the output of one interaction.You can specify an exact string, or use special characters(described overleaf).
: Is the separator between the message syntax and the actionsyntax.
action_if_OK Is action to be executed if the received string matches whatwas expected in <receive_string>.You can:− specify further send_ and receive_strings, using the syntaxdescribed above, but enclosed by parentheses,− not specify any action, in which case the next line of thefile is then executed,− specify the standard (^) symbol. This means that theSQL*Net driver must return control to the calling processorwith an error.
action_if_error Is action to be executed if the received string does not matchthe returned message.You have the same possibilities as for <action_if_OK>above.
When the last line of the autologon file has been executed, and the (^) symbol has notbeen encountered, the connection has succeeded. Control is returned to the callingprocessor.
SQL*Net V1 with ORACLE7 User's Guide
4-14 47 A2 13UR Rev00
4.3.3.2 Special characters
ex "MODEL types"* Specifies 'any character string'.For example: *MODEL (any character string ending with theword MODEL)Specifies 'any single character'.
(^) Specifies that control must be returned to the callingprocessor with an error. Used only in the action syntax.
\t Specifies a single transmit.
\ Protects certain characters when they appear in strings to besent or received.This is because otherwise they would signify something else.Such characters are * : . \ ? ( )For example: \* or: \\
\o Specifies a time-out limit. It is followed by an integer whichspecifies a number of seconds before time-out.For example: \o30 ( 30 seconds time-out )
4.3.3.3 A simple example
(\o10\t?*MODEL: )::(^)
This example does the following: sets the time-out value to 10 seconds, sends a singletransmit, and expects a string ending with the string MODEL: .
If a string ending with MODEL: is received, the next line (not shown) is executed;otherwise the connection fails.
4.3.3.4 Default autologon files
ex "PC autologon files"ex "PC default autologon files"ex "LOG7_SYN default autologonfile"ex "LOG7_ASY default autologon file"Two files are delivered to provide defaultautomatic log-on for synchronous and asynchronous lines.
They are called LOG7_SYN and LOG7_ASY respectively.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
ex "AUTOEXEC.BAT file"ex "ORACLE_HOME variable"ex "Macro variables"ex "Macrodefinition"ex "PC macro variables"One way of improving the efficiency of the autologonprocedure is to define macro variables .
Macro variables are useful because they:
• Reduce the amount of necessary user input during the connection phase
• Reduce the workload when, for example, modifications are to be made to autologonfiles.
The list of macro variables must be stored in the CONFIG.ORA file on the PC, under theORACLE installation directory. The name of this directory is the value of the variableORACLE_HOME. It is usually set to \ORACLE in the AUTOEXEC.BAT file, as follows:
SET ORACLE_HOME=\ORACLE
4.3.4.1 Defining macros
Macros are defined via the following syntax:
<macro_name> = <value>
SQL*Net V1 with ORACLE7 User's Guide
4-16 47 A2 13UR Rev00
Examples:
DB70 =\ORACLE\NET\LOG7,ARE2,JONES,JNS:ORA
OR7=ORA
MB=,ORACLE,ARE2,ORAOPER5,ORA
Macro definitions can contain references to other macros:
Example:
DBS=SYN7:%MB%:%OR7%
Macros are referenced via the following syntax:
%<macro-name>%
Example:
%DB70%
4.3.4.2 Further information
ex "Macro definition"Macro variables can be referenced in the value of other macrodefinitions anywhere after the B: driver prefix. They can be put into host strings, and intothe autologon files themselves.
Examples:
In the CONFIG.ORA file, you can store macro definitions:
DB70S=SYN7:%DB70% SITE=... MB =.........and so on
At the MS-DOS C> prompt, you can enter:
C> SQLPLUS SCOTT/TIGER@B:%DB70S%
or C> SQLPLUS SCOTT/TIGER@B:SYN7:%MB%:ORA.GH
In an autologon file, you can say:
(CN -MB ORACLE -SC %SITE% and so on ... )
You can use macro variables with all commands which are specific to SQL*Net. Forexample, CREATE DATABASE LINK.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-17
4.3.5 Default Database Connection
ex "LOCAL definition"ex "SQLPLUS command"ex "Default database ,local"ex "REMOTEdefinition"ex "Default database ,remote"You can set default database connections, bothfor local and for remote databases.
To do this, you use the LOCAL and REMOTE definitions in the CONFIG.ORA file.
4.3.5.1 Local Connection
The LOCAL definition is used to set up a default local database.
Example :
LOCAL=B:ASY7:\ORACLE\NET\LOG7,ARE2,JONES,JNS:ORA
If the above example is stored in the CONFIG.ORA file, you can enter :
C> SQLPLUS SCOTT/TIGER
and SQL*Plus will connect you (by default) to the database ORA at site ARE2, using theASY7 driver (assuming the LOG7 file is the one shown in Appendix A).
4.3.5.2 Remote Connection
The REMOTE definition is used to set up a default remote database.
If the above example is stored in the CONFIG.ORA file, you can enter:
C> SQLPLUS SCOTT/TIGER@B :
and SQL*Plus will connect you (by default) to the database ORACLE at site LYR1, usingthe SYN7 driver (assuming the LOG7 file is the one shown in Appendix A).
SQL*Net V1 with ORACLE7 User's Guide
4-18 47 A2 13UR Rev00
4.3.6 Requesting Trace Messages
ex "LOG7.TRC trace file"ex "Trace file"If there are problems with an autologon file, youcan first try to execute the log-on procedure manually, as shown earlier. This will enableyou to see what kind of error is causing the problem.
It can also be useful to trace the log-on and collect the trace in a special trace file. Thefile will store all the messages which are sent and received during the autologon phase,and enable you to see clearly where the problem is.
The trace file is called LOG7.TRC. It is stored under the same directory as the defaultautologon file LOG7.
LOG7.TRC must already exist before the trace session starts.
You can do this by typing, for example:
C> COPY LOG7 LOG7.TRC
This creates a copy of LOG7 under the name LOG7.TRC .
The existing contents of the LOG7.TRC file are always overwritten by the most recentlyexecuted autologon dialog.
If no <file-path-name> parameter is defined in the command line (see the paragraph"Autologon" above), then these files must be located in a directory named\ORACLE5\NET.
SQL*Net on a PC Under MS-DOS (synchronous and asynchronous protocols)
47 A2 13UR Rev00 4-19
MS-DOS standard f i le. You general lyf ind a statement l ike
S E T O R A C L E _ H O M E
which sets the d i rectory of ORACLE
the di rectory of ORACLEon your PC
\AUTO EXEC.BAT
the directory of SQL*Net f i les the ORACLE conf igurat ion f i le, containing the macro def ini t ion and the default local and remote database connect ions
the defaul t autologonf i le for SQLNET7
the f i le that receivesthe t race messagesof the autologon faci l i ty
the code of the ASY7 dr iver
the code of the SYN7 dr iver
executab le S Q L*N et code
the com m on driver extens ion ,loaded by S Q LN E T 7.C O M or S Q L6003.C O Mexecution , on ly if O R A C LE c ode has a lready been loaded
MS-DOS standard f i le must conta in thedef ini t ion of the SQL*Net dr ivers
the code o f the correc t type o fin te rface fo r the A T LA N T IScard shou ld a lso be ins ta lled here
\O R A C LE 7
\O R A C LE 7
\O R A C LE 7\N E T \O R A C LE 7\C O N FIG .O R A
\O R A C LE 7\N E T \<code>
D E V IC E =\O R A C LE 7\N E T\D _A S Y 7.B IN ...D E V IC E =\O R A C LE 7\N E T\D _S Y N 7.B IN ...
\O R A C LE 5\N E T \LO G 7
\O R A C LE 5\N E T \LO G 7.TR C
\O R A C LE 7\N E T \S Q LN E T .P XE
\O R A C LE 7\N E T \S Q LN E T .C O M
\O R A C LE 7\N E T \S Q L6003.C O M
\O R A C LE 7\N E T \D _A S Y 7.B IN
\O R A C LE 7\N E T \D _S Y N 7.B IN
\O R A C LE 5defau lt d irec to ry fo rau to logon fac ility
\O R A C LE 5\N E T
or
Figure 4-1. MS-DOS Files and Directories Under SQL*NET Error! Reference sourcenot found.
SQL*Net V1 with ORACLE7 User's Guide
4-20 47 A2 13UR Rev00
47 A2 13UR Rev00 g-1
Glossary
Asynchronous terminalA terminal which transmits and receives data one character at a time.
Asynchronous transmissionData transmission in which the time intervals between transmitted characters may beof uneven length. Transmission is controlled by start and stop elements at thebeginning and end of each character.
Autologon filesSee "handshake files".
Baud rateThe transmission speed, equal to the number of discrete conditions or signal eventsper second.
ClientThe machine where the application resides.
Client/server modelIn the client/server model of communication, the client system (which may be a PC,mini or mainframe) must request the services of the server (or host) computer. Thehost may be a mini or mainframe, but can never be a PC.
Database LinkAn object stored in the local database which identifies a remote database, acommunication path to the remote database, and optionally, a username andpassword for it. Once defined, the database link is used to perform queries on tablesin the remote database.
Distributed databaseA distributed database is composed of parts which may be held in geographicallyseparate locations. When using a distributed database users do not need to knowwhere the data is, and distributed processing is performed in such a way that istransparent to them.
Distributed processingDatabase operations are performed across a network, but users must identify thelocation of the remote data, and must send messages across the network to initiate aprocess on the remote host.
SQL*Net V1 with ORACLE7 User's Guide
g-2 47 A2 13UR Rev00
DSA (Distributed Systems Architecture)Bull architecture for networked systems and products. Consists of a set of protocolsand service definitions in a seven-layer structure as proposed by the Open SystemsInterconnection model (OSI).
Handshake filesFiles which contain a dialogue that will be used to communicate with the remote host.They are used to automate the "conversation" which would otherwise take placebetween the terminal user and the remote host system.
HostThe machine where the database resides and runs the ORACLE kernel, thussupporting the server.
InternetNetwork protocol.
NodeA single physical location on the network.
OPEN7New GCOS 7 subsystem providing Unix commands for TCP/IP.
Public1. Visible or available to all users. Synonyms and database links can be public. Only
DBAs can create public objects. Any user may GRANT PUBLIC access to his ownobjects.
2. A group to which every database user belongs - the name of that group.
ProtocolsA set of standards which govern the operations of a communications link.
Synchronous terminalA terminal which transmits and receives data one field or one screen at a time.
TCP/IPTransmission control protocol/Internet protocol.
Terminal protocolA communications protocol in which the client end of the link behaves like a dumbterminal; that is, asynchronous communication.
Two-task architectureThe technique whereby two separate tasks, or processes, communicate with oneanother to accomplish a single job. For example, the ORACLE kernel (acting as theserver processor) and an ORACLE application (acting as the front-end or drivingprocess).
