Connecting to Oracle AI Database 26ai from a Client PC

You have configured a listener on the server, a tnsnames.ora entry on the client, and a service name that resolves correctly. Now it is time to actually connect. This lesson covers the CONNECT command itself: the syntax, the privileges involved, and one genuine error worth understanding before it catches you by surprise.

To connect as an administrative user in Oracle AI Database 26ai, you use one of two privileged connection types: SYSDBA or SYSOPER. Each grants a different scope of administrative capability, and each requires you to state which one you are using explicitly, as part of the CONNECT command itself.

CONNECT username/password AS SYSDBA;

or

CONNECT username/password AS SYSOPER;

Replace username with the name of a user granted the SYSDBA or SYSOPER privilege, and password with that user's password. If you are connecting over Oracle Net from a client machine, rather than locally on the database server, include the network service name too:

CONNECT username/password@service_name AS SYSDBA;

The service_name here should be a value defined in your tnsnames.ora file, using SERVICE_NAME rather than a bare SID, consistent with how this course has handled service names since Lesson 7.

Connections as SYSDBA or SYSOPER allow privileged operations, so use them sparingly and deliberately. Follow the principle of least privilege: assign only the access a given role actually requires, and reserve SYSDBA connections for the administrative tasks that genuinely need them.

One detail worth stating plainly for a multitenant environment: since every database in Oracle AI Database 26ai is a container database, connecting "to the database" from a client PC almost always means connecting to a specific PDB's service, not to the CDB in some general sense. The syntax looks like this:

CONNECT SYS@pdb_name AS SYSDBA;

This is the same pattern this course has used since Lesson 7, applied here specifically to an administrative connection: pdb_name resolves through your tnsnames.ora entry to a particular PDB's service, and that is exactly which container you end up connected to.

Older Oracle material, and older versions of this lesson, describe a command called CONNECT INTERNAL as the way to connect with full administrative privileges. That command no longer exists in any supported Oracle release: it was tied specifically to the Server Manager tool, and it disappeared along with Server Manager itself, which has been deprecated since Oracle 9i. If you encounter CONNECT INTERNAL referenced anywhere, treat it as a historical artifact, not something to type into a modern SQL*Plus session.

The replacement is exactly the SYSDBA and SYSOPER syntax covered above. Where CONNECT INTERNAL once granted unconditional administrative access with a single special password, current Oracle Database ties administrative access to specific, named privileges instead, each requiring its own authorization path.

Older material also describes a concept called the "internal user" and a separate "internal password," distinct from any regular user password, required specifically for remote administrative connections. That framework does not exist in current Oracle documentation either. The modern equivalent, already covered in this course's earlier work on changing the SYS and SYSTEM passwords, is simpler to state directly than to reconstruct from old terminology: SYS is a CDB common user, and whether a remote SYSDBA connection using ALTER USER works directly, or requires the ORAPWD utility instead, depends entirely on how the REMOTE_LOGIN_PASSWORDFILE parameter is configured. There is no separate "internal password" concept layered on top of that: there is SYS's own password, managed through the same password file mechanism covered in that earlier lesson.

For now, and for most of the connectivity work in this module, connecting as SYSTEM is the more practical path. SYSTEM is the default DBA username created alongside every new database, and you already set its password back when you created your COIN database. Assuming the tnsnames.ora entry named coin resolves correctly, connecting looks like this:

CONNECT system/your_system_password@coin

It is worth deliberately seeing a connection fail once, so the error message is familiar rather than alarming the first time it happens for real. Suppose you attempt to connect to COIN, but your ORACLE_SID environment variable is not set correctly, or the listener is not actually running:

C:\>sqlplus system/your_system_password@coin

SQL*Plus: Release 26.0.0.0.0 - Production

ORA-12560: Database communication protocol error

This error indicates a lower-level communication protocol adapter problem. It can arise from an incorrectly configured connection address, or from errors returned by the underlying protocol or operating system interface itself. It is not always a serious problem, and it is nothing to panic over: check the error stack for additional detail, confirm the protocol specification used in your connection address is correct, and if the cause is still unclear, turn on network tracing, rerun the attempt, then turn tracing back off once you have what you need. Often, the cause is simpler than any of that: the listener is not running, or the service name you specified does not match anything in tnsnames.ora.

With the listener running and the correct credentials, the same command succeeds:

C:\>sqlplus system/your_system_password@coin

SQL*Plus: Release 26.0.0.0.0 - Production

Connected to:
Oracle AI Database 26ai

SQL>

You are now connected to the COIN database as SYSTEM, ready to issue SQL statements against it. This is the same underlying mechanism as every connection covered throughout this module: a service name resolved through tnsnames.ora, a listener that accepted the request, and a username and password Oracle Net validated on your behalf.

One broader note worth keeping in mind as you move beyond this course's local, on-premises setup: modern connectivity options extend well past the tnsnames.ora and SQL*Net approach this module has focused on. Easy Connect Plus and OCI-native connection methods offer additional ways to reach a 26ai database, particularly relevant in cloud-hosted environments. See Oracle 23ai and OCI service connection methods for that broader picture once you are ready to look beyond the local naming approach this course teaches.

And as with every tnsnames.ora entry this module has built, the habits matter as much as the syntax: adopt a predictable naming and distribution strategy across your client machines, and test each new entry with tnsping before relying on it in practice. See creating and maintaining tnsnames.ora for that strategy in full.

Now that you have seen it, go ahead and try it yourself. Click on the Exercise link below to connect to your COIN service.
Connect Oracle Net Service - Exercise

[1]service: An Oracle Net service is usually a database instance, or more precisely in a multitenant environment, a specific PDB, though it can refer to other software accessible through Oracle Net. On Windows, the listener itself runs as a background Windows service, independent of any logged-on user.