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.  

Conclusion:

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