We are receiving The Data Dictionary is not configured analysis warnings within SonarQube itself and, before making changes, wish to understand a couple of things that are not made clear in the PL/SQL documentation
Where is the database connection made from? I am sure that would be within our Jenkins (otherwise I cannot imagine that things would work to well if using SonarCloudOne). One developer’s initial response was “There is no realistic or reliable way to allow SonarQube to ‘connect’ to a database”, so obviously it is possible to interpret the documentation in more than one way.
What are the criteria for sonar.plsql.jdbc.url? For Oracle, can it be a local Oracle XE rather than a full-blown Oracle server? Exact same version of the database that server that the PL/SQL will eventually be used on? Must the server be running a valid test database? I am reckoning that the answer to this very last one is “no” because the documented parameters make no mention of database name.
I ask all this to emphasise that the documentation should not assume that the reader has specific skills or knowledge.
The database connection is created during the analysis by the scanner, not by SonarQube. If you use Jenkins, the database connection would come from the Jenkins server or the Jenkins slave.
It it’s not “relastic or reliable” in your context, you can just disable the rules which are mentioned in the warning.
It can be any kind of Oracle database provided that you can create a JDBC connection to it. It certainly does not have to be your production database. The PL/SQL analyzer uses the connection to get an Oracle dictionary which provides metadata such as column names and types. The analyzer is then able to run a few additional bug detection rules on the analyzed code. The actual content of the tables is never read.
I’m not sure what you mean. The JDBC URL may contain an Oracle SID or service name. See a few examples of JDBC URLs.
Thank you for this feedback. We will consider improving this part of the documentation.
Thank you very much for the response. It was a real help and I have now got rid of the PL/SQL data dictionary analysis warning (displayed in SonarQube server). However, it’s obvious that I am going to have to roll back my change (for now) and instead switch to a quality profile that disables the rules that use data dictionary.
The reason? Using SonarScanner CLI 4.5.0.2216…
INFO: Loading Data Dictionary from jdbc:oracle:thin:@foo.bar.com:1521:XE
INFO: Data Dictionary contains 29 schemas, 11366 tables, 129152 columns, loaded in 101802365 ms
That’s a whole lot of ms. Over 28 hours! After Christmas, I can talk to the team responsible and see about tweaking things (database URL, SID, etc).
The reason I mention all this is… whilst it’s great that things did not fail, could not (should not) there have been better logging of “Loading Data Dictionary” progress/status?
Such performance is definitely not expected.
28 hours is huge, even to load data for 129152 columns.
I would be curious to know how we get so terrible results.
I agree with you that the user experience is bad but I don’t think it’s great that the analysis did not fail. I don’t think anyone would accept such performance, so I would prefer the analysis to fail with a clear message. I created SONARPLSQL-756 to do that.