When analyzing the behaviour of datavirtuality Server in order to trace activities of the server or perform debugging, it is recommended to have a look at the log files in the datavirtuality Server's directory. There is one log file that contains all the information from the last server startup and another file that writes all queries and errors. The files and their location are as follows:
(per Best Practise: /opt/datavirtuality/dvserver/standalone/log/boot.log)
(per Best Practise: /opt/datavirtuality/dvserver/standalone/log/server.log)
(per Best Practise: C:\Program Files(x86)\datavirtuality\dvserver\standalone\log\boot.log)
(per Best Practise: C:\Program Files(x86)\datavirtuality\dvserver\standalone\log\server.log)
Some typical information which you can get from the boot.log files are
- The connections used for the configuration databases, if different from H2
- JAVA_HOME system environment variable that is used
- Java runtime which the server runs on
- The machine's hostname and Fully Qualified Domain Name (FQDN)
- Several important directories that are being used
- Memory settings of the Java Virtual Machine
- and many more
Here are some sample lines extracted from a boot.log. The server from the sample uses a PostgreSQL DBMS to host the two configuration databases. The connection for this is named 'dvconfigs_pg'. The JAVA_HOME can be found and the running Java version is Java 7 Update 60 which is from Oracle. You can also see that the name of the server's host machine is 'dv-pc' and it does not belong to a domain (i.e. belongs not to an environment that uses Directory Services like Active Directory or OpenLDAP). Lastly, the extract show the path to the server.log file. The meaning of the memory setting is explained in the section Memory Management of the Admin Guide.
All the actions performed by the datavirtuality Server are logged in this file. You will also find the commands that were sent to the server as well as possible errors that occured. Typical information in the log is about connection timeouts, valid licenses and many more. Note that, like all the other popular DBMS, datavirtuality Server uses an SQL statement for all operations. This has the advantage that you can track all the modifications that might have been made to the server options, optimization jobs or additional flags that were used when a statement was executed. Many of this information is also visible in the Query Log which you can access via datavirtualtiy Studio, but the server.log has stored information regarding datavirtuality and you can use tools like Tail or FarManager to watch the log live. This is useful if you want to or have to audit sever actions. The major application of the log is troubleshooting. While datavirtuality Studio only gives an error message after a failed query run, you have the stack trace in the server.log file to check all the errors that preceeded the message which the user saw and you can also follow the erros that do not come with any error message at all. When your connection to the internal database cannot be established, for example, the server will be unavailable and there will be no messages via the Studio because it cannot connect to the server. The log provides this information and you can start checking the network connection to the DBMS that hosts the configuration database.
Stored procedures used for logging
Tests if logging is enabled at the given level and context.
Returns true if logging is enabled. Level can be one of the log4j levels: OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE. level defaults to 'DEBUG' and context defaults to 'org.Data Virtuality Server.PROCESSOR'
Log a message to the underlying logging system.
Returns true if the message was logged. level can be one of the log4j levels: OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE. level defaults to 'DEBUG' and context defaults to 'org.Data Virtuality Server.PROCESSOR'
This will log the message 'My debug message' at the level INFO to the context COM.DATAVIRTUALITY.MYDEBUG.