{ "date": "2018-06-01T10:36:09", "slug": "sqlcl-connect-target-depends-on-previous-connection", "link": "https://www.dbi-services.com/blog/sqlcl-connect-target-depends-on-previous-connection/", "title": { "rendered": "SQLcl connect target depends on previous connection" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nI thought it was a bug for two reasons: first, because I don’t like that my connect destination depends on the context, and then because it is a different behavior than in SQL*Plus. But finally, it is the correct behavior, and the 100% compatibility with SQL*Plus is expected only when SET CLASSIC=ON. And as I was surprised, and I think it can be dangerous, here is a blog post about it. Basically, be very careful if you are connected with a service name and you want to connect locally.
\n
\nBasically, if you attended my demo about ‘From Transportable Tablespaces to Pluggable Databases’, where I switch between different instances you may have seen that I had to run ‘connect / as sysdba’ two times because the first one failed with invalid username/password

\n
\nSQL> connect scott/tiger@//localhost/PDB1\nConnected.\n...\nSQL> connect / as sysdba\nUSER =\nURL = jdbc:oracle:oci8:@//localhost/PDB1\nError Message = ORA-01017: invalid username/password; logon denied\n \nWarning: You are no longer connected to ORACLE.\n \nSQL> connect / as sysdba\nConnected.\n
\n

This is not a big deal, but that means that it tries to connect to //localhost/PDB1 when I wanted to connect locally to my ORACLE_SID environment variable. Here, expecting a bequeath connection, I didn’t provide a password, then I cannot connect to the PDB. But imagine that I use a password, and the password is the same in the two databases… I would have been connected to the wrong database. Just imagine this:

\n
\nSQL> host echo $ORACLE_SID\nTEST\nSQL> connect sys/password as sysdba\nConnected.\n-- checking something on PROD\nSQL> connect sys/password@PROD as sysdba\nConnected.\n...\n-- back to TEST (or at least I think so)\nSQL> host echo $ORACLE_SID\nTEST\nSQL> connect sys/password as sysdba\nConnected.\n-- do terrible things\nSQL> drop table VERY_IMPORTANT_TABLE;\nTable VERY_IMPORTANT_TABLE dropped.\n-- now look where I am:\nSQL> show connection\nCONNECTION:\nSYS@jdbc:oracle:oci8:@PROD AS SYSDBA\nCONNECTION_IDENTIFIER:\nPROD\n
\n

Actually, what happens is that when SQLcl is already connected with a connection string (i.e not locally using bequeath) the next connect command will use the same connection string. This means that:

\n
\nconnect user/password\n
\n

is actually equivalent to

\n
\nconnect user/password@&_CONNECT_IDENTIFIER\n
\n

SQL*Plus

\n

This behavior has been introduced in SQLcl but this is not how SQL*Plus works:

\n
\nSQL> connect sys/oracle@//localhost/PDB1 as sysdba\nConnected.\nSQL> connect / as sysdba\nConnected.\nSQL> define _CONNECT_IDENTIFIER\nDEFINE _CONNECT_IDENTIFIER = \"CDB1\" (CHAR)\n
\n

Disconnect

\n

The first solution to avoid this in SQLcl is to always disconnect before you want to connect to a different service:

\n
\nSQL> connect sys/oracle@//localhost/PDB1 as sysdba\nConnected.\nSQL> disc\n \nDisconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\nVersion 18.2.0.0.0\nSQL> connect sys/oracle as sysdba\nConnected.\nSQL> show connection\nCONNECTION:\nSYS@jdbc:oracle:oci8:@ AS SYSDBA\nCONNECTION_IDENTIFIER:\nCDB$ROOT\n
\n

This is why the second time was ok in my case: first one failed with invalid password and then I was disconnected.

\n

TWO_TASK

\n

The second solution is to set an impossible TWO_TASK (or LOCAL in Windows) so that local connections are impossible:

\n
\nSQL> connect sys/oracle@//localhost/PDB1 as sysdba\nConnected.\nSQL> connect sys/oracle as sysdba\nUSER = sys\nURL = jdbc:oracle:oci8:@NoWhere\nError Message = ORA-12154: TNS:could not resolve the connect identifier specified\nUSER = sys\nURL = jdbc:oracle:thin:@NoWhere\nError Message = IO Error: Unknown host specified\nUSER = sys\nURL = jdbc:oracle:thin:@NoWhere:1521/NoWhere\nError Message = IO Error: Unknown host specified\n
\n

CLASSIC=ON

\n

The third solution is to run SQLcl in SQL*Plus 100% compatible mode:

\n
\nSQL> connect sys/oracle@//localhost/PDB1 as sysdba\nConnected.\nSQL> set classic on\nSQL> show classic\nSQL*Plus mode: ON\nSQL> connect / as sysdba\nConnected.\n
\n

Here we have the same behavior as SQL*Plus: no use of current connection string.

\n

The SQL CLASSIC ON is usually for the output (error messages, autotrace statistics, and a few enhancement made to SQLcl). And the online help still says that it is about output:

\n
\nSQL> help set classic\nSET CLASSIC\nSET CLASSIC [ ON | OFF ]\nSet classic SQL*Plus Settings on\nThis will allow scripts which expect traditional output to be honored.\n
\n

However, it seems that this CLASSIC mode is also very important for connection.

\n

Test and show _CONNECTION_STRING

\n

If you show the connection string at the prompt, this may prevent errors:

\n
\nSQL> set sqlprompt \"_connect_identifier> \"\n//localhost/CDB2> connect sys/oracle@//localhost/CDB1 as sysdba\nConnected.\n//localhost/CDB1> connect sys/oracle as sysdba\nConnected.\n
\n

Always check which database

\n

By the way, when I prepare a script that can make some damages when not run at the correct place, I usually add a test on DBID on top of it:

\n
\nCDB1> whenever sqlerror exit failure;\nCDB1> select 0/decode(dbid,'944121612',1,0) from v$database;\n \nError starting at line : 1 in command -\nselect 0/decode(dbid,'944121612',1,0) from v$database\nError report -\nORA-01476: divisor is equal to zero\n
\n

Different passwords

\n

Of course, you should have different passwords on prod and test databases. However, I prefer to have passwords in a wallet (external password file) and then you will always have the correct identification as it is recorded for each service name.

\n", "protected": false } }