September 26, 2017

News Regarding Post "bind csid (#) does not match session csid (#)"

Problem "bind csid (#) does not match session csid (#)"

After further investigation and analysis, here some more news regarding the problem with "bind csid (#) does not match session csid (#)"

I wrote: "Reason was - in my case - that an agent, which has connected to a freshly created clone of a production database a little to early, was stuck with an Character Set which was current at the time of the first connect."

Additional information: 

Found out that the agent has used the 'sys' account of the database as monitoring user. That means, after the cloning process has finished and the database has been starting, the agent connected to the database using this account. Because sys (or any sysdba) is able to connect to a database which is not in an open state ... You know what I mean: The agent connected much too early, got US7ASCII as character set, and ran finally into the "bind csid does not match ..." error.  


There are more options to fix that problem than mentioned in the first post regarding this topic:

  • restart the agent will solve the problem
  • if the database is a result of a recurring cloning process, do not use 'sys' as monitoring user, but 'dbsnmp'
  • generally: do not use 'sys' as a monitoring user, except for Dataguard 
  • After a system restart, start the databases first and subsequently the agent - if You have to use 'sys' as monitoring user for whatever reason
  • monitor the trace directory to avoid that tracefiles are filling up the filesystem


August 16, 2017

SQLcl - the SQL*Plus plus a plus ...

"euphoric: intensely happy or confident", @thatjeffsmith, ...

Just watched the video from @thatjeffsmith about SQLcl - and it is, indeed, worth the time. After looking that video, I'm pretty sure that SQLcl will replace SQL*Plus within months (if some more people 'spread the word').

Just a few keywords to make you curious:

  • SQLcl is available as 'standalone' download, but it is also already part of the latest SQLDeveloper 17.2.0
  • SQLcl needs an JRE to run 
  • To start SQLcl use 'sql' - not 'sqlcl'
  • SQLcl has almost all features included, SQL*Plus has (simply run Your sql scripts in SQLcl instead of SQL*Plus)
  • Once started, type help and You'll see all the new commands available. For example:
    • alias - define aliases for often used SQL-Commands
    • cd - change directory when within SQLcl
    • ctas - simply type 'ctas <table> <new-table>' and You'll get the complete syntax for a 'Create Table As Select'. The ctas is loaded into the SQLcl buffer, so You could simply issue a '/' and the code is executed. Ok - You have to edit the result, because of ORA-02264 errors (Constraint already exists - but thats easy done by typing ed to start the editor
    • SQLcl eases typing of statements. It can autocomplete column and table names. Example: Type 'select * from hr.empl<tab>' and it automatically autocompletes to hr.employees. If more than one possibility is available, it lists all ...
    • DDL - a command to extract the ddl for a given object
    • info - a 'verbose' desc which displays way more information about an object
    • info+ - yes, info+! An even more informational view on an object. Interestingly, neither info nor info+ are shown when issuing an help command. But 'help information' will show how to use it.
    • history - show the last 100 command You'd issued in SQLcl (customizable to any value). Even more: You can use history <index> (where index is the number of a sql statement in the history) to load a sql statement in buffer - execute it by typing / , edit it (ed) or change values using the good old 'c/<old value>/<new value>

And there is a lot more - repeat for example, which repeats a statement n times, sleeping t seconds between each execution. Watch the video and then try SQLcl!

"euphoric: intensely happy or confident" - Yes, I am :-)


July 31, 2017

July 6, 2017

ODA X6-2S - upgrade from to ... just a few remarks

Did an update of our ODA X6-2S from to Patch Bundle and want to share some findings. 

The patching process is described quite good in the README - nevertheless, a few remarks:

  • the whole process took about 2 hours - without downloading the necessary files and preparations (for example: read the README ;-))
  • The time, the update process takes, depends on the number of databases running on that system (in our case just four)
  • The README does not clearly mention that the system is rebooted two times. 
    First time after step odacli update-serversecond after step odacli update-storageBut not immediately after the update step - the system waits for 5 Minutes until it starts rebooting (!)
    Do not start any following step before the reboot has taken place and the system is available again
  • README chapter 4 - Post Patching Steps - tells not the whole truth: oracle talks about issuing an update-image command. But, in the Image-Patch README is mentioned that You have to issue a

    odacli update-repository --fileName /tmp/

    Long story told short:
    1. do the 'update-repository' step first 
    2. '--fileName' will throw an error - the command is: '--filename' (all lower case) or - alternatively '-f'
    3. after updating the repository, issue the update-image

That's it, basically. Happy upgrading!


June 28, 2017

bind csid (#) does not match session csid (#)


A database's alert log is full of messages like

Wed Jun 28 09:13:09 2017
Errors in file /cloudfs/adr/diag/rdbms/scs12fi/SCS12FI/trace/SCS12FI_ora_16694.trc:
Wed Jun 28 09:13:10 2017
Errors in file /cloudfs/adr/diag/rdbms/scs12fi/SCS12FI/trace/SCS12FI_ora_16694.trc:
Wed Jun 28 09:13:13 2017
Errors in file /cloudfs/adr/diag/rdbms/scs12fi/SCS12FI/trace/SCS12FI_ora_16694.trc:
Wed Jun 28 09:16:25 2017

Errors in file /cloudfs/adr/diag/rdbms/scs12fi/SCS12FI/trace/SCS12FI_ora_16694.trc:

The trace file shows
psdgbt: bind csid (1) does not match session csid (31)

psdgbt: session charset is WE8ISO8859P1


MOS Note "After restart of database suddenly PLS-00553: character set name is not recognized are seen in the alert.log (Doc ID 1599864.1)" is not exactly a description of what has happend, but points in the correct direction.

Reason was - in my case - that an agent which has connected to a freshly created clone of a production database a little to early was stuck with an Character Set which was current at the time of the first connect. After the database has been fully started, the correct charset is used - which now does not fit anymore to the session charset used by the agent connect.


in my case: simply restart the agent ...

June 26, 2017

EM 13c: TNS-01190 errors when listener owner and agent owner are not the same account


When monitoring listener's logfile, lots of TNS-01190 are found:

<msg time='2017-06-26T10:21:47.608+02:00' org_id='oracle' comp_id='tnslsnr'
 type='UNKNOWN' level='16' host_id='edosrvoda03'
 <txt>26-JUN-2017 10:21:47 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=edosrvoda03)(USER=oracle))(COMMAND=trc_directory)(ARGUMENTS=2)(SERVICE=LISTENER)(VERSION=202375680)) * trc_directory * 1190
<msg time='2017-06-26T10:21:47.608+02:00' org_id='oracle' comp_id='tnslsnr'
 type='UNKNOWN' level='16' host_id='edosrvoda03'
 <txt>TNS-01190: The user is not authorized to execute the requested listener command


The owners of the agent process is different from the listener process owner. Example: agent is installed and run under user account 'oracle' - listener is started by user 'grid'. 

Reproducability: Every time, Enterprise Manager tries to discover or rediscover new targets on a system, these TNS-01190 errors will occur in listener's logfile. So, try a rediscover on a certain host - after that, You'll find TNS-01190 errors in the listener log.


MOS Note "How To Disable Oracle Database Listener Alerts TNS-01190 In Enterprise Manager Cloud Control to avoid the error "trc_directory (TNS-1190), log_directory (TNS-1190),. Please check log for details." (Doc ID 1399060.1)" recommends two possible solutions:

  1. set a listener password and include that password in 'Monitoring Configuration' of the listener target.
    This recommendation does not work for listeners of version 12.1 and higher, because the password feature is no longer supported.
  2. edit the metric and remove the 1190 string from the list of values.
    Remains the only possibility ... change Your monitoring template and/or target setting, edit TNS Errors / TNSMsg and replace 'TNS-[ ]*0*(1169|1189|12508|1190)' with 'TNS-[ ]*0*(1169|1189|12508)' (remove the '|1190') or - and that's imho the best way - do not monitor TNSMsgs ...

June 19, 2017

dbca - db creation stops with dbmssml.sql error


Trying to create a database using dbca on a Oracle Linux 7 running in a Virtualbox Container. DBCA throws an error during database creation: something like "dbmssml.sql. refer to dbmssml0.log error in process: perl". The mentioned log file is empty.


Important!: It is NOT a database software or a dbca problem. Additionally, if You run a 'perl -v' command, You'll receive a 'segmentation error' - this is, too, not a database, nor a perl problem. Instead, it is a Virtualbox 5 issue.

Found the solution for that here: Oracle DB12c / OL7 / VBox 5 – Perl Segmentation Fault

Copyright © Robert Crames' Oracle Database and Middleware Blog | Powered by Blogger
Design by SimpleWpThemes | Blogger Theme by