A typical installation will require a minimum of 400Mb of hard disk space to install the code, samples, documentation and sample database. The database will need additional space for data inserted, backups, logs and reports, web pages, etc.
The size of the database .db file will not reduce when data is removed. The spare space will however be reclaimed for later use.
The Virtuoso database requires a minimum of 64Mb of system memory for each instance to operate in. Each connection will take between 70kb and 130kb of memory.
The memory usage is affected by the following parameters in the Virtuoso configuration file.
See the following Parameter section for more details.
Virtuoso runs on the following operating systems:
The below table lists the most important parameters and limits for a database or a Virtuoso server instance. For space consumption of individual data types, see Space Consumption.
Multiple Virtuoso server instances may coexist on a single machine. Each database will need to be assigned a unique TCP port number. On the windows platforms (except 95,98,ME) the Virtuoso can be configured for multiple services. For further details, see the Creating and Deleting Virtuoso Services in the Installation chapter.
To run Virtuoso on a machine, only the Virtuoso server executable and a valid virtuoso.ini file are needed. An empty database file will be created automatically at first startup. None of the other files in the installation are needed for basic operation. Client interfaces may additionally need ODBC drivers or the like to be set up in system configuration files or the Windows registry but the server itself does not depend on these.
Virtuoso comes with optionally installable SQL application packages (VAD packages) for web based admin, on-line documentation, programming tutorials and a BPEL processor. The installer typically asks whether to install these into the demo or the default empty database. Depending on the OS and form of installer, also depending on whether the installation is the commercial or open source one, the package files will be in different locations. To locate them, look for *.vad. The packages are typically made in two variants, where one keeps the installed items in the DAV repository and the other in the file system. They are functionally equivalent in most cases, except for some tutorials that will only work in the file system. Keeping installed resources in DAV has advantages when moving the database or backing up, since the installed items will not have to be treated separately. To install these on a database, login as dba using the isql utility and issue the SQL command:
# at the OS command line prompt, assuming the dba password is dba and the server is at the default port 1111: $ isql 1111 dba dba -- At the SQL prompt: SQL> vad_install ('conductor_dav.vad', 0); -- The path is relative to the server's working directory.
Since the packages are read from and sometimes the extracted contents are written to the file system, the server must have access to the directories in question. Checjk OS permissions and set the DirsAllowed parameter in the ini file to allow the needed access.
After the packages are installed, they can be used by pointing the web browser to their start page. The start pages are listed on the root page of the demo database and at the Getting Started section of the Open Virtuoso web site. The start page for the Conductor web admin interface is /conductor, the docs are at /doc/html, the tutorials at /tutorial, the BPEL admin and demos at /BPELGUI. All these are directly under the default Virtuoso web listener, the port is shown in the messages log and read from the HTTP Server section of the virtuoso.ini file.
The Virtuoso server requires a valid license file before it will successfully start. The license file is a file always called virtuoso.lic and must reside in the working directory of the database instance - where the <database-name>.db file resides for the instance.
Evaluations versions of Virtuoso come without a license file, however the registration procedure takes your email address, which will be used to email a new license file for you evaluation.
Virtuoso provides extensive log information for resolving problems. Should any problems arise Virtuoso logs should always be consulted.
The Virtuoso server by default will send log information to two places, the appropriate system log for the operating system and the virtuoso.log file. On Unix based operating systems, including Linux, this information will appear in the system log files. On Windows the Virtuoso log information will appear in the Application Event Log.
Virtuoso logs information in the system logs before the Virtuoso.log file is open. This advantageously will log errors that cannot be placed in the virtuoso.log file, such as when the virtuoso.ini file cannot be located during Virtuoso startup.
The system log feature can be disabled using the "Syslog" parameter in the [Database] section. This is described in more detail in the following section.
The virtuoso.ini file is read from the directory that is current at server startup. This file contains an entry for all user settable options in the server. It is divided into the following sections:
[Database] Location of database files
[Parameters] Server tuning, options
[HTTPServer] Settings in this section control the web server component of the Virtuoso Server.
[URIQA] Settings in this optional section control URIQA semantic web enabler.
[SPARQL] Settings in this optional section control SPARQL protocol endpoint default parameters and limits.
[Replication] The replication section sets the transactional replication parameters for the server.
[Mono] The Mono section contains settings pertenent to using the Virtuoso with Mono Runtime CLR support.
[Client] Client default settings
[AutoRepair] Corrupted database recovery
[Striping] Multi-file / multi-disk databases
[VDB] Virtual database functionality related options
[Ucms] location of UCM files describing multi-byte encodings such as Far East languages
[Zero Config] ZeroConfig related options
[Plugins] VSEI plugin modules
Below are the descriptions for each parameter
For a single file database, this is the relative path of the file in the format appropriate to the platform. The path is resolved relative to the directory that is current at server startup. All other paths are interpreted similarly.
This is the transaction log file. If this parameter is omitted, which should never be the case in practice, the database will run without log, meaning that it cannot recover transactions committed since last checkpoint if it should abnormally terminate. There is always a single log file for one server. The file grows as transactions get committed until a checkpoint is reached at which time the transactions are applied to the database file and the trx file is reclaimed, unless CheckpointAuditTrail is enabled.
This file logs database error messages, e.g. 'out of disk'. By viewing this the dba can trace problems and see at which times the server has started, checkpoints have been made, etc.
This controls what events get logged into the database error log. This should always be 7.
This optional parameter can be used to manually specify the location of the Virtuoso lock (.lck) file. This can be relative or the full path to the lock file. Virtuoso, by default, creates a file with the same name as the DatabaseFile but with the extension of .lck. This file exists when the Virtuoso server is running to prevent it starting multiple times using the same parameters, and should be automatically removed by the server upon exit. However, not all file systems support file locking, such as NFS, therefore this parameter can be set to keep the lock file on a more appropriate file system.
This is the size that the database file automatically grows (in 8k pages) when the current file is not large enough. Default = minimum = 100. The parameter has no effect if striping is set.
A non-zero value will enable the settings in [Striping] to take effect. If this is the case the DatabaseFile parameter is ignored and the files in [striping] are used.
If this is non-zero log segmentation is enabled. This is only used for crash dumps where several files may be needed to accommodate the recovery logs. If non-zero, this will be followed by entries of the form Log1=...
The number in Log<n> is the ordinal number of the log, starting at 1. The entry consists of the file name and allocated size with an optional size modifier. Available modifiers are B for blocks of 4k (default if unspecified, K for kilobytes, M for megabytes, and G for gigabytes. The log is filled up to the first transaction that exceeds the size. The log therefore will be longer than the allocated size. If blobs are involved, this amount can be quite substantial. It is therefore advisable to have some extra space available on the storage device used for recovery logs.
These options make it possible to produce a crash dump of a specified range of disk pages. In case the server runs out of disk space during a dump, the error message indicates the page at which the next dump should be started after the user has made more space available. In this case it is important to rename the already produced crash dump or change the Logx= -entries in virtuoso.ini to avoid overwriting said files. If none of these options are provided, the server will attempt a crash dump of the entire database storage.
The name of a section in the INI file containing temporary database details. If this parameter is omitted or the section does not exist the default values for temporary storage are used.
Virtuoso normally writes log worthy messages to the system log (Unix based operating systems including Linux) or the Windows Event Log (Windows operating systems). Messages are written in the system/event log before the virtuoso.log file is opened, therefore errors due to absence of virtuoso.ini log are loggable there. This system/event logging can be disabled using this option, by default it is set to 1 meaning on.
On Unix/Linux messages are written as "Virtuoso" events.
On Windows messages are written in the Application event log.
This section name must match the TempStorage parameter in the Database section of the Virtuoso INI file to be of any use. Otherwise this section will be ignored.
Name of temporary database file.
Name of temporary transaction file.
Increment amount by which the database file will dynamically grow. This setting is identical in use and purpose to parameter in the Database section with the same name.
This is a Win32 specific option that forces Virtuoso to only run on one CPU in a multiprocessor environment.
This is the IP Address and port number where the server will start listening. You do not need to specify the listening IP Address but can do in a situation that you want the server to bind to a specific address only.
This is the maximum number of threads used in the server. This should be close to the number of concurrent connections if heavy usage is expected. Different systems have different limitations on threads per process but a value of 100 should work in most places.
Stack size of thread used for reading client messages and accepting connections.(default : 50 000 bytes)
Stack size of the main thread (default : 100 000 bytes)
The interval in minutes (default : 0) after which threads in the thread pool should be released.
The maximum number of threads (default : 10) to leave in the thread queue after thread clean-up interval has expired.
The interval in minutes (default : 0) after which allocated resources will be flushed..
Stack size of worker threads. This is the stack size for serving any client SQL statements or HTTP requests. This can be increased if the application uses recursive stored procedures or links in external code needing a large stack. (default 100 000 bytes)
A Percentage that may be greater than 100%. This gives a percentage of the main .db file to which the temp db file may grow before starting to reclaim the oldest persistent hash index. Basically if a particular hash index is reusable (i.e. it references only table columns and the values in these columns have not changed) the engine keeps the hash index defined into the temp db for reuse. This parameter allows some control over the temp db file size.
If this is non-zero, the database file(s) will be opened with the O_DIRECT option on platforms where this is supported. This has the effect of doing file system IO from application buffers directly, bypassing caching by the operating system. This may be useful if a large fraction of RAM is configured as database buffers. If this is on, the file system cache will not grow at the expense of the database process, for example it is less likely to swap out memory that Virtuoso uses for its own database buffers. Mileage will vary according to operating system and version. For large databases where most of system memory is used for database buffers it is advisable to try this.
This is the interval in minutes at which Virtuoso will automatically make a database checkpoint. The automatic checkpoint will not be made if there is less than MinAutoCheckpointSize bytes in the current transaction log. A checkpoint interval of 0 means that no periodic automatic checkpoints are made.
Setting the value to -1 disables also the checkpoints made after a roll forward upon database startup. This setting should be used when backing up the database file(s). This guarantees that even if the server dies and restarts during the copy, no checkpoints that would change these files will take place and thus the backup is clean.
the checkpoint_interval SQL function may be used to change the checkpoint interval value while the database is running.
This controls how the file system is synchronized after a checkpoint. Once the checkpoint has issued all write system calls it needs it can do one of the following depending on this setting:
0. - Continue, leave the OS to flush buffers when it will.
1. - Initiate the flush but do not wait for it to complete.
2. - Block until the OS has flushed all writes pertaining to any of the database files.
This controls the amount of RAM used by Virtuoso to cache database files. This has a critical performance impact and thus the value should be fairly high for large databases. Exceeding physical memory in this setting will have a significant negative impact. For a database-only server about 65% of available RAM could be configured for database buffers.
Each buffer caches one 8K page of data and occupies approximately 8700 bytes of memory.
Specifies how many pages Virtuoso is allowed to remap. Remapping means that pages can consume the space of two actual pages until checkpoint. See the Checkpoint & Page Remapping section in the SQL Reference chapter for more information.
This setting should always be 0.
This controls the case sensitivity of the Virtuoso SQL interpreter. The following values are supported:
0 - SQL is case sensitive and identifiers are stored in the case they are entered in. This is similar to the Progress or Informix default.
1 - SQL is case sensitive and Unquoted identifiers are converted to upper case when read. To use non-upper case identifiers, the identifiers must be quoted with double quotes ("). This is similar to Oracle.
2 - SQL is case-insensitive and identifiers are stored in the case where first seen. Unlike the situation in other modes, two identifiers differing only in case cannot exist. This is similar to the MS SQL Server 7 default behavior.
Once a database is created in one case mode the case mode should not be changed as that may change the interpretation of stored procedures etc.
See CheckpointInterval.
This is the size of transaction log in bytes after which an automatic checkpoint is initiated. If this is non-zero, whenever the transaction log size exceeds this size an automatic checkpoint is started. This will result in approximately like sized logs to be generated. This is useful with the CheckpointAuditTrail option for generating a trail of equal sized consecutive logs.
If this is non-zero each checkpoint will start a new log and leave the old transaction log untouched. A 0 value indicates that the transaction log may be reused once the transactions in it have been written in a checkpoint.
If it is important to keep an audit trail of all transactions in the database's life time then this option should be true. A new log file will be generated in the old log file's directory with a name ending with the date and time of the new log file's creation. Old log files can be manually copied into backup storage or deleted. Only one log file is active at one time. The newest log file may at any time be written to by the server, but that is the only log file Virtuoso has open at each time. Thus reading any logs is safe. Writing or deleting the active log file will result in loss of data, and possibly referential integrity, in the database. See the Back and Recovery chapter for more information on this and related parameters.
If non-zero the system SQL function is enabled. This will allow a dba group user to run shell commands through SQL. This poses a potential security risk and hence the setting should normally be 0.
This is the maximum number of rows returned by a static cursor. Default = 5000
This is the amount of text data processed in one batch of the free-text index when doing a batch update or non-incrementally reindexing the data. Default : 10,000,000
When set to 1, if an application prepares a statement with insufficient number of input parameters, the unspecified ones are assumed to be NULL.
Defines a sorting order according to SYS_COLLATIONS. The name supplied to this parameter must be in charsets_list(1).
<path> := <absolute_path> or <relative_path> comma-delimited list of OS directories allowed for file operations such as file_to_string(). The server base directory (the directory containing this INI file) must appear on this list in order to enable File DSNs to work.
<path> := <absolute_path> or <relative_path> OS directories denied for file operations. See Virtuoso ACL's for information on functions that are restricted.
Specifies the port on which the server listens for incoming SSL CLI requests.
The SSL certificate to use (same meaning as the SSLCertificate in HTTPServer section)
The server's private key (same meaning as the SSLCertificate in HTTPServer section)
This parameter governs the maximum number of partial or full join orders that the Virtuoso SQL Optimized compiler will calculate per select statement. When MaxOptimizeLayouts has been reached, the best execution plan reached thus far will be used. The default value is 1000, specifying 0 will try all possible orders and guarantee that the best plan is reached.
This parameter accepts a comma-delimited list of tracing options to activate by default. Enabled trace options will list there respective errors in the virtuoso.log file when encountered. Valid options are:
If an invalid option is set then this error will be listed in the virtuoso.log file upon server startup. Virtuoso will continue to log selected options unless the trace_off() function is called for that item.
The functions: trace_on() and trace_off() which use the same options and can turn logging options on/off while the server is running.
[Parameters] .... TraceOn = soap, errors ...
This will enable logging of additional information regarding SOAP calls and SQL run-time errors into the virtuoso.log file.
Determines whether Virtuoso encryption should be accepted from client connections. The default value is 1 - on. If set to 0 then only clear text and digest authentication will be accepted.
This parameter is applied to the environment prior to the server's startup. It is valid only for binaries hosted in the Virtuoso Java VM. This has the same format as the Java CLASSPATH environment variable for the platform being used.
Virtuoso searches for classes in the following order:
These can be used for setting Java options for the Java runtime hosted in Virtuoso. These options work as if provided as command line options to the JRE's Java command line.
More than one line of options can be specified by using consecutively numbered options:
JavaVMOption1 = -Ddt1=val1 JavaVMOption2 = -Ddt2=val2 ... JavaVMOption5 = -Ddt5=val5
The PLDebug switch controls the type of debugging enabled:
Controls whether Virtuoso will report call stack on errors.
This parameters takes the following values:
This controls whether Virtuoso will recompile all stored procedures listed in SYS_PROCEDURES and internal PL procedures defined during server startup. By default Virtuoso will recompile all procedures, with this setting set to 0 Virtuoso will defer compilation until procedures' first call. The benefits of this are that Virtuoso may start up up to 2-3 times faster, also the initial memory consumption will be significantly reduced as it does not need to analyze all the long varchar data allocating memory for execution. This setting is a boolean, either 1 or 0. This setting does not apply to attached VDB procedures or modules.
Controls the number of file descriptors per file to be obtained from the OS. The default and minimum value is 1. This parameter only effects databases that use striping. Having multiple FDs per file means that as many concurrent IO operations may simultaneously be pending per file. This allows more flexibility for the OS to schedule the operations, potentially improving file I/O throughput
This option controls the behavior of free-text triggers in super-tables. If this option is set to 1 then Virtuoso will scan the hierarchy of tables until a free-text index is used to use when compiling SQL statements involving contains, xcontains or xpath_contains.
This option controls the behavior of super-table triggers. When this option is set to 1 then triggers in the super-table will be called before its own (sub-table) triggers. This behavior is recursive and will continue up the branch of recursion, hence the triggers in the top most table in the chain will be called first.
The TOP select statement clause caches in memory the rows pertinentent to the result. The number of rows allowed to be cached within memory is limited by this parameter.
This parameter is only applicable to Unix servers. Virtuoso clients on the localhost of the server can benefit from using Unix Domain sockets to improve connection performance. By default (DisableUnixSocket = 0) Virtuoso will open a Unix Domain listen socket in addition to the TCP listen socket. The name of the UD socket is /tmp/virt-<tcp-listen-port>. When a client attempts to connect to the Virtuoso server using the specific address localhost it will first try connecting to the UD socket, failing that it will silently revert to the TCP socket. See the Unix Domain Socket Connections section for more details.
When the roll-forward log entry of a transaction exceeds this size, the transaction is too large and is marked as uncommittable. This work as upper limit otherwise infinite (transactions). The default is 50Mb . Then also note that transaction roll-back data takes about 2x of roll-forward data. Hence when the transaction roll-forward data wich is 50Mb the total transient consumption is closer to 150 Mb.
Directory for storing temporary data for large object handled in replication and HTTP server. Defaults to server home directory.
Enable or disable Database Event Hooks.
Specifies the OS user name to witch the server will switch after opening the listen ports. Has an effect only on the operating systems that support it.
Specifies the limit of the memory to be used for compiling a SQL statement. If the query compilation requires more memory an error will be signalled. If this is a zero then no limit will be apllied. The default is 10Mb i.e. when no parameter is specified, also if negative number or less than 5000000 is given then it would be set to 5000000 bytes.
This specifies the default transaction isolation. This isolation is used unless overridden by a client setting it using the SQL_TXN_ISOLATION or equivalent connection option or a stored procedure locally setting it with the SET statement. The values are as by the SQL_TXN_ constants in ODBC, that is, 1 for read uncommitted, 2 for read committed, 4 for repeatable read and 8 for serializable. If nothing is specified, the default is repeatable read.
This specifies whether to use asynchronous file I/O on supporting Unix systems. A value of 0 means not using it. A value of 1 means using lio_listio for any background write or read ahead if available. A value of 2 means to use the regular blocking read and write but to merge adjacent operations into a single system call when possible.
Controls the acceptable size of the temp database file. If on startup it's size (in MB) is greater than TempDBSize the file gets deleted and reset. This feature can be turned off by setting TempDBSize to 0. Note that the temp db file serves as an optimization storage only and doesn't have any client data that are not in either the main database files or the corresponding transaction log files.
Settings in this section control the web server component of the Virtuoso Server.
This specifies the initial HTTP listen port for the HTTP server. Once Virtuoso is started it is possible to create multiple listeners using virtual directories.
The stack size of the HTTP thread used for reading/processing HTTP client requests and accepting connections. The default is 120,000 bytes. This parameter cannot have value less than the default; if a smaller value is specified the default will be used.
This specifies the number of concurrently serviced HTTP requests. If there are more concurrent requests, accepting the connections will be deferred until there is a thread ready to serve each. If an attempt to exceed the number of licensed connections is found. the latter will be used. When the number of threads is low some of the tutorials may perform poorly and appear not to work; this is due to the demonstration licensing. When testing Virtuoso with the demonstration license it can be quite easy to hit the limits unless remote connections and HTTP connections are conserved. You may wish to either wait for previous transactions to finish or restart the server to be sure.
The stack size of HTTP thread used for reading/processing HTTP client requests and accepting connections. The default setting, if not supplied, is 120,000 bytes. The default value is the minimum; lesser values will be rounded up.
This is the file system path of the root directory of files served by the Virtuoso web server. The index.html in that directory will be served for the / URI. If relative, the path is interpreted relative to the server's working directory.
String passed as Server: header to HTTP client. This string is not required, in its absence the above default will be assumed. This string can be set to anything required.
String passed as User-Agent: header to server by HTTP client. This string is not required, in its absence the above default will be assumed. This string can be set to anything required.
Allows you to set the default server character set. If no default is specified then ISO-8859-1 will be used automatically by the server.
This sets the default behavior of HTTP transmission. If set to 1 The Virtuoso HTTP server will send GZipped content to user agents. Otherwise content will be sent as is. The function http_enable_gz() lets you change the server mode on the fly.
Connections by HTTP 1.1 clients can remain open after the initial response has been sent. This parameters sets a cap on how many socket descriptors will at most be taken by keep alive connections. Such connections will be dropped by the server ahead of timeout if this number would be exceeded. Thus the maximum number of open sockets for the Virtuoso HTTP server is this number plus the number of threads. A keep alive connection is by definition not associated to any pending processing on any thread.
This is a timeout in seconds before Virtuoso closes an idle HTTP 1.1 connection.
Setting this to 1 activates Virtuoso proxy service capabilities. The default value of 0 deactivates the proxy service.
Ports on which proxying is enabled should not be presented to the outside world under any situation.
If specified, Virtuoso will produce an HTTP server log file with the date appended to the name given in the parameter and the files extention as ".out". The log file is rotated daily.
It will contain the following information:
logDDMMYYYY.out :-
An example of which is:
127.0.0.1 - - [12/Sep/2006:12:31:17 +0300] "GET /ods/ HTTP/1.1" 200 19453 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko.." 127.0.0.1 - - [12/Sep/2006:12:31:18 +0300] "GET /ods/default.css HTTP/1.1" 200 41389 "http://localhost:8894/ods/" "Mozilla/5.0 (Windows; U; ..." 127.0.0.1 - - [12/Sep/2006:12:31:19 +0300] "GET /ods/common.js HTTP/1.1" 200 7481 "http://localhost:8894/ods/" "Mozilla/5.0 (Windows; U; ..."
When Virtuoso is acting as a proxy or HTTP client, as is the case with the http_get or the SOAP client functions, it caches connections to HTTP 1.1 servers. This is the maximum population of said cache.
This is a timeout in seconds for dropping idle connections to other HTTP servers. These result from http_get, SOAP client functions and proxying.
This specifies the root path of DAV resources. If DAV specific HTTP methods are used on Virtuoso, these should only reference resources with paths starting with this. This is the top level DAV collection. Other paths can be declared as managed in DAV using the virtual directory mechanism, but this applies to the default virtual directory.
The Virtuoso administrator can enforce a quota on all DAV accounts, apart from the "dav" administration user, that restricts that amount of space a DAV user can consume in their DAV home directory. When this parameter is set to one (1) quotas are enabled, when this parameter is set to zero (0), they are disabled. The default quota value is five Megabytes (5MB) but can be uniquely defined for each user. Every user has a quota except "dav", which is unlimited. Dav quotas are disabled if this parameter is not specified for backwards compatibility.
Virtuoso send resources to from WebDAV to the requesting client in chunked encoding to save memory if the request is in HTTP/1.1 and the files size is greater then the DAVChunkedQuota number of bytes. The default chunked-quota value is approximately one-megabyte.
this is the port on which SSL HTTPS connections will be accepted. If unspecified then the service will be disabled.
the option must point to the file with the server certificate in PEM format.
points to the file containing the RSA private key in PEM format.
the certificate/key pair must be valid (eq. certificate is generated on base of key)
Defines the TCP port number on which the Virtuoso POP3 server will listen. The POP3 server will be disabled if this value is 0 or undefined.
Defines the TCP port number on which the Virtuoso NNTP server will listen. The NNTP server will be disabled if this value is 0 or undefined.
The Virtuoso FTP server can be enabled by supplying this parameter with a value. This value will then be the listening port of the FTP server. The usual port for FTP is port 21.
The Virtuoso FTP client and server use FTPServerMinFreePort and FTPServerMaxFreePort parameters as lower and upper bounds for active and passive connections. This parameters sets the lower bound.
The Virtuoso FTP client and server use FTPServerMinFreePort and FTPServerMacFreePort parameters as lower and upper bounds for active and passive connections. This parameters sets the upper bound.
If specified Virtuoso will produce an FTP server log file with the date appended to the name given in the parameter and the files extention as ".log". The log file is rotated daily.
It will contain the following information:
ftpserverDDMMYYYY.log :-
An example of which is:
hostname anonymous [22/Oct/2003:15:21:43 +0300] "PASS user@domain.com" 230 0 hostname anonymous [22/Oct/2003:15:23:11 +0300] "LIST" 226 162 hostname dav [22/Oct/2003:15:25:00 +0300] "PASS <hidden>" 230 0
Allows the FTP server to be accessible via the "anonymous" user login. The anonymous user is not a real user, it has no SQL or DAV login ability. The anonymous user can only access collections or resources that are set to public.
Default SMTP server name and port, this is used when the first parameter of the smtp_send function is omitted or NULL.
Allows you to choose what file system directory to be used for temporary storage of ASPX files hosted in DAV.
When set to "1" prevents Virtuoso from removing the plugin interpretters from the HTTP threads after each request. The default setting is "0".
The size threshold for large objects recieved by HTTP server. When this limit is exceeded by incoming or outgoing data, this will be stored in a temp file, see 'TempSesDir' parameter in 'Parameters' section.
The name of a HTML page or other static content to be returned to the user agents when server is running in atomic mode. Note that this page should be self-contained, i.e. no image or CSS not JavaScript references can be used.
The URIQA section sets parameters of both URIQA HTTP extension and URIQA web service. Section URIQA Semantic Web Enabler contains detailed description of this functionality, including more details about URIQA configuration parameters. This section should stay commented out as long as URIQA is not in use.
The server name, including domain and port if needed, such as "www.example.com" or "www.example.com:8088".
List of various allowed spellings of the server name, such as "www.example.com, mail.example.com, mail, localhost, localhost.localdomain".
List of various allowed spellings of the server name in form of pattern strings for SQL "like" operator, not in form of exact strings.
Do not use this without an explicit need, to let server configure itself. Please refer to detailed description before use.
The SPARQL section sets parameters and limits for SPARQL query protocol web service service. This section should stay commented out as long as SPARQL is not in use.
Section RDF Database and SPARQL contains detailed description of this functionality.This controls processing of the "query-uri" parameter of the SPARQL query protocol webservice, means enable 1 or prohibited 0.
This controls processing of the "xslt-uri" parameter of the SPARQL query protocol webservice, means enable 1 or prohibited 0.
This setting is used to limit the number of the rows in the result, if this is higher than "maxrows" parameter this setting takes precedence.
IRI of the default graph to be used if no "default-graph-uri" parameter is specified.
This setting is used to limit the estimate time cost of the query to certain number of seconds, the default is no limit.
This setting is used to set the transaction execution timeout to certain limit in number of seconds, the default is no limit.
The replication section sets the transactional replication parameters for the server.
A boolean parameter controlling whether a Virtuoso can or cannot act as a transactional replication publisher.
This identifies the server instance. The entries in SYS_REPL_ACCOUNTS where SERVER equals this name are considered locally published accounts. This is the value returned by repl_this_server () SQL function.
This controls how much synchronized transactional subscribers may fall behind before being disconnected. This controls how much memory the server will use to buffer undelivered replication casts. If the queue exceeds this byte amount subscribers are disconnected and must request re-synchronization. The byte count refers to the total length of the replay records being buffered. The actual memory usage is somewhat greater.
A path to the directory where the Mono system assemblies are located. Usually it is a compile time setting, but the MONO_ROOT overrides it. This ini setting overrides the Mono environment variable of the same name.
A colon separated list of directories where the assemblies are located to be found by Assembly.Load (equivalent to MS.NET Global assembly cache). This ini setting overrides the Mono environment variable of the same name.
A path where the 'machine.config' file is to be found while running the ASPX code in Mono. This ini setting overrides an environment variable of the same name. This is also usually a Mono compile time default.
A fully qualified path and filename of the virtclr.dll virtuoso helper assembly.
Mono debug tracing can be enabled by setting this parameter to On. When tracing is On, Mono debug output with be sent to the Virtuoso debug console.
This sets the initial value of the SQL_QUERY_TIMEOUT statement option in connected clients. The ODBC standard value is 0, meaning indefinite, which is impractical in many applications. This allows overriding the default. The timeout is expressed in seconds. If the client application sets this option in a statement, this default is overridden for the statement in question.
This is an ODBC extension option allowing setting a maximum duration for a transaction. 0 means that there is no maximum.
For a forward only cursor, this option sets the number of rows prefetched at the execute and on subsequent fetch requests. A high value will speed up long selects but will be a disadvantage if only the first few rows are fetched from a cursor that has a large result set.
This should not be confused with the SQL_ROWSET_SIZE setting for scrollable cursors.
This option specifies the maximum number of bytes the server will send as prefetched rows on a forward only cursor. If long rows are being prefetched this will cut off the prefetch after this many bytes even if the number of rows is less than SQL_ROWSET_SIZE.
This options is 0 by default and can be either 1 or 0. This option controls Virtuoso's interpretation of the backslash in PL text which is normal interpreted as escaping rather than literal.
Setting SQL_UTF8_EXECS = 1 enables UTF-8 identifier storage and retrieval, whereas setting SQL_UTF8_EXECS = 0 disables it. The default setting is 0: disabled for backwards compatible. See the Wide Character Identifiers section for more information
When SQL_BINARY_TIMESTAMP is set to 1 Virtuoso will describe all TIMESTAMP columns as SQL_BINARY. If it is set to 0 then Virtuoso will report the TIMESTAMP columns as SQL_TIMESTAMP
This setting can be used to prevent SQLTables from returning system tables. The default value of this setting is 0, which is allow system tables to be returned in the normal way. Setting this to 1 will prevent system tables from being returned from SQLTables. The client can also issue a "set SQL_NO_SYSTEM_TABLE = 1/0" statement to set this in-connection.
As a result of an internal error in the database the physical integrity of references may be lost. Enabling this option causes the database to automatically repair such faults without having to go through a crash dump plus restore. A value of 0 should be normally used.
Boolean parameter which allows the Virtuoso VDB to use Array parameters if the remote data source supports these.
This parameter turns on/off MTS support in Virtuoso. It is applicable to windows multithreaded version of the Virtuoso server only.
Specifies a size of the parameter batch used by the VDB (default = 10)
The time (in seconds) after which a VDB connection is considered timed-out and closed. Default : 1000
This setting can be enabled to improve compatibility with the MS Oracle Driver which has problems with mixed case table names in catalog calls.
Boolean parameter : allows a special mode for the ORACLE ODBC drivers which do not return correct catalog data for mixed case tables. When this is on and the return from the catalog functions is empty, then a Catalog function is issued to take the same catalog data and the result is filtered on the client side.
An boolean parameter controlling whether the VDB Catalog functions called while attaching a table will be called in AutoCommit mode (required by some Sybase drivers).
The default setting of 0 instructs the VDB layer to return underlying DB errors to the client rather than automatically reconnecting without reporting the error, which would be setting 1.
The default option is 1, this forces the VDB to map a single thread to each ODBC session in the VDB rather than multiple threads. Some ODBC drivers expect that calls concerning a particular connection all take place on one thread. For example, the Oracle 8.xx ODBC driver can produce flaky crashes if this option is not set.
0 - If a second request comes while a thread is processing the epilogue or previous request for same connection the second request is scheduled for the same thread. This is called burst mode. Once this mode is active all requests on this connection will be processed in the same thread. until there is a break at delay more than 'PrpcBurstTimeoutMsecs' elapces between ending the last and recieving the next in same connection. This break in activity return the thread to the thread pool. The burst mode optimization saves thread switching time and may improve performance by up to 30% in situations involving short requests immediately following each other.
"ForcedFixedThread" mode (4). This is the same as VDBFixedThread mode, except that the thread enters this state immediately on connection (as opposed to doing that on the first VDB activity). Otherwise the scheduling stays the same as in VDB FixedThread.
"Forced Burst" mode (8). When a connection is initially made it's added to the select thread for monitoring. When an RPC comes in it causes the select thread to take the connection out of the select thread and assign that connection to designated worker thread. That thread from now on will read the data comming in from that connection directly (not depending on the select thread to detect the incoming data and wake the worker thread up). That mode saves the thread switch done handling each RPC (from the select thread to the worker thread). When the connection terminates the thread is unbound from it and returned to it's default idle state. If an lengthy RPC is being processed the server will switch the thread from burst mode to default mode while running the RPC, so the asynchronous cancelation requests can be processed.
To disable ever going to burst mode, this option can be set to 2
RPC burst mode timeout in miliseconds. (see above)
When enabled causes Virtuoso to wrap SQLAllocConnect/SQLConnect calls sequence in a mutex, thus preventing abnormal program exits when there are a large number of connection requests to the VDB. Certain ODBC drivers have been noted to produce flaky errors when a large number of threads is concurrently inside one of the ODBC connect calls..
This setting controlls SQL compilation (not execution) for conditions where rows in a local table are used to determine rows of a remote table to be deleted (e.g. delete from rmt1 where rmc1 = 12 and rmc2 in (select lc1 from lt1)) where the remote table was linked without a Primary Key primary key specified. Normally the primary key is used, even when not in the original select select, to identify the rows to be deleted. When the primary key is false or not available and SkipDMLPrimaryKey = 1 then the original where clause will be used instead.
This option controls the SQL compiler ability to do some optimizations when it knows it will receive 1 row from a remote table (using the applicable WHERE clause). In some cases the remote is not providing any info about a primary key (or is providing wrong data for the primary keys and unique indices of a table) through ODBC API and the Virtuoso SQL optimizer may get fooled into thinking that a given SQL query over a remote table will return no more than 1 row. To avoid that turn on the above parameter to stop the compiler from doing that optimizations.
This option controls the aggregation point of the VDB connection pools. When it is off (=0, the default) the VDB connections that are no longer needed after transaction end are collected server-side in a per-user connection cache. This (together with the KeepConnectionOnFixedThread INI option) ensures conformance even with older ODBC drivers that require that connections must be used only within the OS thread that initiated them. This however may result in somewhat low reuse rate for the pooled connections. That's why when this option is 1 (On) the connections are stored in a server-side per-DSN connection cache. Keep in mind that this may not work with all the ODBC drivers, but it may provide lower ratio between virtuoso client connections and VDB-to-remote DBMS connections, thus requiring smaller number of active connections on the remotes and faster execution of VDB operations.
String parameter which specifies the path where UCM files are located. If this parameter is not specified, UCM files cannot be loaded.
Every UcmN parameter specifies one UCM file to load. The value of UcmN is a pair of comma delimited strings. The first string is a name of the UCM file to load, (relative to the path specified in UcmPath), the second string is a name of the encoding as it was used by the server. E.g. Ucm1 = java-Cp933-1.3-P.ucm,Cp933 will load the encoding from the file java-Cp933-1.3-P.ucm and associate it with the identifier 'Cp933'. You can register one encoding with more than one name, if they are delimited by '|' (with no white spaces in the string). e.g. Ucm2 = java-Cp949-1.3-P.ucm,Cp949|Korean will load the encoding from the file java-Cp949-1.3-P.ucm and associate it with two identifiers, 'Cp949' and 'Korean'. See UCM Encodings for more details.
Name used to advertise the Virtuoso ODBC service details in ZeroConfig. This is the name that will be shown to clients amongst other ZeroConfig datasources.
An ODBC style connect string to preset the values of the parameters when the ODBC service offered by this server is selected by the Virtuoso ZeroConfig enabled clients.
Name used to advertise the Virtuoso ODBC SSL encrypted service details in ZeroConfig.
An ODBC style connect string to preset the values of the parameters when the ODBC SSL encrypted service offered by this server is selected by the Virtuoso ZeroConfig enabled clients.
The Zero Config section.
The directory containing shared objects/libraries for use as Virtuoso VSEI plugins.
<number> is the module load number, required and starting with 1. <module type> specifies the type of module that is to be loaded, and hence how Virtuoso is to use it. So far only the "Hosting" type exists. <module name> is the file name of the modules shared library or object. (e.g. Load1 = Hosting, hosting_perl.so)
<number> must be ordered from 1 upwards; The <size> is the size of the segment which is equally divided across all stripes comprising the segment.
This section is only effective when Striping = 1 is set in the [Database] section. When striping is enabled the Virtuoso database spans multiple segments where each segment can have multiple stripes.
Striping can be used to distribute the database across multiple locations of a file system for performance. Segmentation can be used for expansion or dealing with file size limitations. To allow for database growth when a file system is near capacity or near the OS file size limitation, new segments can be added on the same or other file systems.
Striping only has a potential performance benefit when striped across multiple devices. Striping on the same file system is needless and unlikely to alter performance, however, multiple segments do provide convenience and flexibility as described above. Striping across partitions on the same device is likely to reduce performance by causing high unnecessary seek times on the physical disk.
Database segments are pre-allocated as defined. This can reduce the potential for file fragmentation which could also provide some performance benefit.
Virtuoso striping alone does not allow for any fault tolerance. This is best handled at the I/O layer or by the operating system. File system RAID with fault-tolerant striping defined should be used to host the Virtuoso files if striping based protection is desired.
The segments are numbered, their segment <number> must be specified in order starting with segment1.
The <size> is the total size of the segment which is that will be divided equally across all stripes comprising the segment. Its specification can be in gigabytes (g), megabytes (m), kilobytes (k) or in database blocks (b) the default.
The segment size must be a multiple of the database page size which is currently 8k. Also, the segment size must be divisible by the number of stripe files contained in the segment.
Segments can be added to a database, however once defined they should never be altered. Databases that were created without striping cannot automatically be restarted with striping. You can convert a non-striping database to striping by dumping the contents of the database to a transaction file and replaying it with striping enabled. An on-line backup made with backup_online () can be restored on a database with a different striping configuration as long as the total number of pages is no less than the number of pages of the backed up database.
Striping can be useful for the temprary objects database if large hash join temporary spaces or such are expected. This is enabled by the Striping setting in the Temp Database section of the ini file. The stripes will be declared in the TempStriping section.
Rebuilding A Database in the Backup section.
Following is the text of the sample virtuoso.ini file that comes with the distribution.
; ; virtuoso.ini ; ; Configuration file for the OpenLink Virtuoso VDBMS Server ; ; ; Database setup ; [Database] DatabaseFile = virtuoso.db TransactionFile = virtuoso.trx ErrorLogFile = virtuoso.log ErrorLogLevel = 7 FileExtend = 200 Striping = 0 ; LogSegments = 1 ; crashdump_start_dp = 0 ; crashdump_end_dp = 0 ; Log1 = log1.trx ; ; Server parameters ; [Parameters] ServerPort = 1111 ServerThreads = 10 CheckpointInterval = 60 CheckpointSync = 2 NumberOfBuffers = 2000 MaxDirtyBuffers = 1200 MaxCheckpointRemap = 2000 PrefixResultNames = 0 CaseMode = 1 ;MinAutoCheckpointSize = 4000000 AutoCheckpointLogSize = 40000000 CheckpointAuditTrail = 1 [HTTPServer] ServerPort = 1122 ServerRoot = ../vsp ServerThreads = 2 MaxKeepAlives = 10 KeepAliveTimeout = 10 MaxCachedProxyConnections = 10 ProxyConnectionCacheTimeout = 15 DavRoot = DAV [Replication] ServerName = log1 Server = 1 QueueMax = 50000 [Client] SQL_QUERY_TIMEOUT = 0 SQL_TXN_TIMEOUT = 0 SQL_PREFETCH_ROWS = 100 SQL_PREFETCH_BYTES = 16000 [AutoRepair] BadParentLinks = 0 BadDTP = 0 ;[Ucms] ;UcmPath = /ucm ;Ucm1 = java-Cp933-1.3-P.ucm,Cp933 ;Ucm2 = java-Cp949-1.3-P.ucm,Cp949|Korean ;Ucm3 = java-ISO2022KR-1.3-P.ucm,ISO2022KR|ISO2022-KR ; ; Striping setup ; ; These parameters have only effect when Striping is set to 1 in the ; [Database] section, in which case the DatabaseFile parameter is ignored. ; ; With striping, the database spans multiple segments ; where each segment can have multiple stripes. ; ; Format of the lines below: ; Segment<number> = <size>, <stripe file name> [, <stripe file name> .. ] ; ; <number> must be ordered from 1 up. ; ; The <size> is the total size of the segment which is equally divided ; across all stripes comprising the segment. Its specification can be in ; gigabytes (g), megabytes (m), kilobytes (k) or in database blocks ; (b, the default) ; ; Note that the segment size must be a multiple of the database page size ; which is currently 8k. Also, the segment size must be divisible by the ; number of stripe files constituting the segment. ; ; The example below creates a 200 meg database striped on two segments ; with two stripes of 50 meg and one of 100 meg. ; ; You can always add more segments to the configuration, but once ; added, do not change the setup. ; [Striping] Segment1 = 100M, db-seg1-1.db, db-seg1-2.db Segment2 = 100M, db-seg2-1.db
When data is inserted into tables, database pages are split and typically pages end up not being fully utilized. If data is inserted in ascending order of key value, which is often the case, space utilization is more efficient. Still, gaps can be left by updates, deletions and page splitting. Virtuoso has an autocompact feature which will take groups of adjacent dirty pages and see if it can fit the same content on a smaller number of pages. It will rewrite the pages to save space before writing these to disk. This operates automatically. Statistics on autocompaction are shown beside the Read ahead status line of the result set of status ('');. The number of pages affected by autocompaction and the number of resulting pages are shown. The numbers are cumulative since the start of the instance.
Autocompact is non-locking and if pages are busy, they will not be touched. Only relatively old dirty pages, about to be written to disk are considered for compaction, not interfering with the hottest part of the working set.
The automatic compaction is not however effective if pages are updated singly, never making stretches of consecutive dirty pages. Therefore a manual compaction function called DB.DBA.VACUUM () is also offered.
The vacuum stored procedure gets an optional table and index name and will read the index from beginning to end. If neither argument is given, all indices of all tables will be compacted. If only the table is given, all indices of this table will be compacted.
If consecutive leaves can be fit on fewer pages than they now occupy, this will rewrite them and free the pages left over. This does however require transient space since the pages are not really replaced until the next checkpoint, hence a vacuum operation can run out of disk. Using the checkpoint statement to force a checkpoint will free the space.
The effects and need for explicitly vacuuming a database can be assessed with the DB.DBA.SYS_INDEX_SPACE_STATS view.
Running:
select * from DB..SYS_INDEX_SPACE_STATS order by ISS_PAGES desc;
produces a result set with the most space consuming index on top. ISS_PAGES is the total count of pages. ISS_ROW_BYTES is the byte count of the rows. If dividing the total count of bytes by the count of pages is much below 8172, (8K - 20), chances are that vacuuming the index may save space. Note that blobs are not affected by vacuuming. If the blobs are small enough to fit on the row as normal strings they are already there. Otherwise they occupy the needed number of pages and cannot be made more compact.
Note that querying the SYS_INDEX_SPACE_STATS view will always read through all the allocated pages of the database and may take a while. The operation is not locking. Only the state as of the last checkpoint will be shown, hence it is a good idea to run the checkpoint statement before querying this view.
Examples:
DB..VACUUM (); -- Compact all tables and indices of the Virtuoso instance
Db..VACUUM ('WS.%'); -- compact all tables of the WS. qualifier
DB..VACUUM ('DB.DBA.RDF_QUAD', 'RDF_QUAD_PGOS'); -- compact the rdf_quad_phgos index of the rdf_quad table.
Virtuoso has an autocompact feature.
This section presents the command line switches of the Virtuoso server executable. Depending on the model and virtual database middleware the server will have different names, all starting with virtuoso-. All these however have the same options for UNIX systems and slightly different for Windows platform.
on Windows platform are available following server command line options:
Usage: virtuoso-odbc-t.exe [-clnCbDARf---dSIMKmrd] [+configfile arg] [+licensefile arg] [+no-checkpoint] [+checkpoint-only] [+backup-dump] [+crash-dump] [+crash-dump-data-ini arg] [+restore-crash-dump] [+foreground] [+pwdold arg] [+pwddba arg] [+pwddav arg] [+debug] [+service arg] [+instance arg] [+mode arg] [+dumpkeys arg] [+manual] [+restore-backup arg] [+debug] +configfile specify an alternate configuration file to use, or a directory where virtuoso.ini can be found +licensefile specify an alternate license file to use, or a directory where virtuoso.ini can be found +no-checkpoint do not checkpoint on startup +checkpoint-only exit as soon as checkpoint on startup is complete +backup-dump dump database into the transaction log, then exit +crash-dump dump inconsistent database into the transaction log, then exit +crash-dump-data-ini specify the DB ini to use for reading the data to dump +restore-crash-dump restore from a crash-dump +foreground run in the foreground +pwdold Old DBA password +pwddba New DBA password +pwddav New DAV password +debug allocate a debugging console +service specify a service action to perform +instance specify a service instance to start/stop/create/delete +mode specify mode options for server startup (onbalr) +dumpkeys specify key id(s) to dump on crash dump (default : all) +manual specify when create a service to make it for manual startup +restore-backup restore from online backup +debug Show additional debugging info The argument to the +service option can be one of the following options start start a service instance stop stop a service instance create create a service instance screate create a service instance without deleting the existing one delete delete a service instance list list all service instances
The below are switches for server for UNIX platforms:
Usage: virtuoso-iodbc-t [-fclnCbDARwMKr---d] [+foreground] [+configfile arg] [+licensefile arg] [+no-checkpoint] [+checkpoint-only] [+backup-dump] [+crash-dump] [+crash-dump-data-ini arg] [+restore-crash-dump] [+wait] [+mode arg] [+dumpkeys arg] [+restore-backup arg] [+pwdold arg] [+pwddba arg] [+pwddav arg] [+debug] +foreground run in the foreground +configfile use alternate configuration file +licensefile use alternate license file +no-checkpoint do not checkpoint on startup +checkpoint-only exit as soon as checkpoint on startup is complete +backup-dump dump database into the transaction log, then exit +crash-dump dump inconsistent database into the transaction log, then exit +crash-dump-data-ini specify the DB ini to use for reading the data to dump +restore-crash-dump restore from a crash-dump +wait wait for background initialization to complete +mode specify mode options for server startup (onbalr) +dumpkeys specify key id(s) to dump on crash dump (default : all) +restore-backup restore from online backup +pwdold Old DBA password +pwddba New DBA password +pwddav New DAV password +debug Show additional debugging info
The +crash-dump option will make use of the segmented log defined in virtuoso.ini for storing the recovery log. See Crash Recovery and virtuoso.ini below for more information. The other options will not use the segmented log.
The +restore-crash-dump option will alter the server startup sequence so that the recovery log produced by +crash-dump will be re-played correctly.
The +mode option can be a combination of the following letters:
On Unix platforms the executable will detach itself from the console and run in the background as a daemon unless the +foreground switch is specified.
For Windows NT and Windows 2000, the Virtuoso server will normally be installed as a Windows service and can be started from the Control Panel or automatically at system startup.
Ordinarily the Windows service will be a system process that runs in the background. If you want the Virtuoso service on Windows to allocate a debugging console the you can use the +debug (-d) switch. This switch is only applicable to starting a service.
Virtuoso on Windows can be run directly from the command line using the +foreground (-f) switch. The server will then start in the foreground of the current "cmd" session. If this switch is not used then the executable on Windows will assume that you are attempting to start a Virtuoso service.
Windows services can be created and removed from the system as required. The default installation under Windows will create a service by the name: OpenLink Virtuoso VDBMS Server, and optionally another service with the name OpenLink Virtuoso VDBMS Server [demo]. The Demo service is a supplied demonstration database that can be installed.
The following options are available to the +service switch for configuring Virtuoso services:
They are used with the +instance <name> where <name> is the instance name to configure a particular instance. All instances are listed in the services applet, with their name in square brackets.
+service list can be used to obtain the list if services that are registered with Windows.
For each service listed you can start, stop, or delete the service.
+service create can be used to create a new service. In this case you also need to specify other start up options that would be associated with the new service entry. If you were using an alternative configuration file this must be specified using +configfile switch.
Make sure the Services Control Panel is closed, before attempting to modify services from the command line, otherwise locking may occur.
The "ZeroConfig" protocol, also known as "Zeroconf" or "Zero Configuration" is a protocol that allows discovery of services on the network that are advertised by their hosts. It also has provisions for automatic discovery of computers and various devices. The main benefit of ZeroConfig is that it does not require DHCP, DNS or directory servers.
ZeroConfig is an open protocol that Apple submitted to the IETF for a standard-creation process.
The Virtuoso server and ODBC driver use the capabilities of ZeroConfig to facilitate DSN (Data Source Name) setup and usage. This is divided in two parts: Server-side and Client-side.
The Virtuoso server (Server-side) is configured via the Virtuoso INI file to advertise its availability on a network with a given name. This allows applications, and in particular the Virtuoso ODBC driver, to receive information about a server, such as its network address, default login, etc, and use it for configuring a data source or directory making a connection.
The Virtuoso ODBC driver (Client side) uses ZeroConfig to locate the desired Virtuoso server during the set-up phase of a data source, and determine available connection options such as:
ZeroConfig provides the client with a service name, which must be bound to the IP address/port of a host of the chosen service during DSN configuration. This is used when existing DSN using a ZeroConfig name is used to connect, it will map name with IP address and port before making a connection.
The Virtuoso server is configured to advertise itself based on the details specified in the [Zero Config] section of the Virtuoso INI file. Below is an example of such:
... [Zero Config] ServerName = Virtuoso Server ServerDSN = UID=demo;PWD= SSLServerName = Virtuoso Server (via SSL) SSLServerDSN = UID=dba;PWD=;ENCRYPT=1 ...
The ServerName and SSLServerName are human readable strings chosen by the administrator to provide clients with a suitable description of the service being provided.
If the Virtuoso does not have the SSL listener enabled then the SSL service will not be advertised automatically. The SSL* keys will simply be ignored and do not need to be removed.
The ServerDSN and SSLServerDSN are default connection strings that can be used by clients to make the advertised connection. You only need to to specify default username and password in these strings. The default database can be specified or left to the setting for the username. You cannot specify the server hostname, IP address or port number, these are supplied by Virtuoso automatically.
ZeroConfig service advertising is multicast, hence it is advertised on all available network interfaces.
Upon DSN set-up the ODBC driver listens for advertising servers, and compiles a roster. This is displayed for the user to choose the desired service to connect to.
If ZeroConfig is used to for data source set-up then the set-up dialog will be initialized based on the details in the connection string configured on the server.
When a DSN is configured based on a ZeroConfig service, the driver will resolve the service name before making the connection to the server. The driver does not store the network address or port number of the Virtuoso server, only the ZeroConfig server name, so if the server's physical address is changed the client DSNs associated with it do not all have to reconfigured; they will resolve to the new address automatically on next use.
The database status report is divided into 6 sections:
This section shows how many connections are open and how many threads the process has and how many are running at the present time. This also displays the number of requests that have been received but are not yet running on any thread.
File size 203161600, 24800 pages, 259 free. 7000 buffers, 6987 used, 3884 dirty 8 wired down, repl age 8251 . Disk Usage: 14246 reads avg 6 msec, 74% read last 10 s, 14457 writes, 4 read ahead, batch = 5. Gate: 2729 2nd in reads, 0 gate write waits, 3372547 in while read 0 busy scrap. Log = wi.log, 9851835 bytes 14950 pages have been changed since last backup (in checkpoint state) Current backup timestamp: 0x0000-0x00-0x00 Last backup date: unknown Clients: 18 connects, max 17 concurrent, 1024 licensed RPC: 54441 calls, 17 pending, 17 max until now, 0 queued, 53988 burst reads (99%), 0 second Checkpoint Remap 7646 pages, 0 mapped back. 0 s atomic time. DB master 24800 total 259 free 7646 remap 3415 mapped back temp 200 total 196 free
The status consists of the following items:
The database file size in bytes or 0 if the database consists of statically allocated files. The total number of 8K database pages follows, then the number of free pages. The number of buffers shown the total count of 8K file cache buffers, followed by the number of used buffers and the number of buffers that are dirty at the time. The wired down count is normally zero but can be transiently other if pages are wired down for processing by threads in the server.
Shows the cumulative total number of reads and writes and the average length of time spent inside the read system call for the database files.
The percentage is the percentage of the real time spent inside read between this status report and the previous status report. This may exceed 100% if several reads are taking place concurrently on different stripes in a multi-file database.
Lists concurrent events. The 2nd in read is the count of concurrent requests for the same page, the gate write waits is the count of times a modify operation had to wait for exclusive access to a page being read by another thread, the in while read is the count of file cache hits that have taken place while a read system call was in progress on another thread.
Thus section shows the count of pages, free pages, checkpoint remap and mapped back for the main database and the space for temporary data such as sort results and hash indices. The page count is the total size, the free count is the count of free pages, the checkpoint remap is the count of pages that occupy two pages in checkpoint space instead of one, the mapped back count is the number of pages that will return to their original place in checkpint space at the next checkpoint. Understanding these is not necessary.
The Disk Configuration section for a discussion of checkpoint remapping.
The lock section shows various locking statistics accumulated since the server was started. The deadlock count is divided into deadlocks caused by a situation where several transactions read a page and one wants to get write access and all other deadlock situations. The first is called 2r1w deadlock in the report.
The lock section also shows the total number of threads running, i.e. engaged in performing some operation for a SQL or web client. The number of threads waiting is the number of running threads that are presently waiting for a lock. The number of threads in vdb is the number of threads engaged in remote database operations or other 'slow' I/O, such as access to outside HTTP or SOAP services.
All locks currently in effect are listed with the owners (a) and possibly waiting transactions. The transactions are named after their client. A log or replication replay transaction is here named 'INTERNAL'.
Each connected client is listed with the number of bytes sent and received from the client. The transaction status is either PENDING for OK or BLOWN OFF or DELTA ROLLED BACK for a transaction killed by deadlock or timeout. The locks owned by the transaction are listed following the status. IE means exclusive and IS shared lock.
This section shows the server in question and a list of replication accounts either provided or received by this server. Accounts where the server name (left column) is the same as the server name are those provided by this.
The columns are server name, account name, last transaction number and status. The status is OFF for a local account or a replicated account where the remote is not available. It is SYNCING if a resync is in progress, IN SYNC if the account is up to date or REMOTE DISCONNECTED if there was a connection to a remote party which subsequently disconnected.
This part of the report summarizes the database's access statistics. The output is a table with a row for each index in the database. Each row is composed of the following columns:
Table The name of the table Index The name of the index. Same as the table for primary key. Touches The number of touches since startup. Each time the database engine looks at an entry of the index is counted as a touch. Not all touched entries are selected. For instance if the engine scans a table with non-indexed selection criteria it will touch each row but might select none. Reads The number of disk reads caused by reading this index. %Miss The percentage of touches that required a read. This can be over 100% since getting one entry may required more than one read if the top levels of the index are not in memory. Locks The number of times a lock is set on an entry of the index. Waits The number of times the engine has to wait for another transaction to finish in order to set a lock on this index. %W The percentage of waits of all locks set.
In interactive SQL
SQL> status();
Will print out the report.
The Virtuoso Service name can be altered using the key Win32ServiceName in the Parameters section. The default name is 'OpenLink Virtuoso VDBMS Server'
To change the name of services:
Services with old names must be deleted before creating service with the new name, i.e. with the Win32ServiceName setting set to the current name of the service.
The name displayed in the ODBC Administrator, Setup and Configuration dialogs is taken from the driver section in the ODBCINST. This can be directly edited in the registry using the regedt32 Windows utility, or a registry import file can be created which can be applied by simply double-clicking the .reg file. Always exercise extreme caution when making changes to the registry.
Virtuoso has the ability to encrypt it's CLI network connections using SSL. The server listens on a separate port for SSL CLI connections and handles them just as the normal CLI connections, vut now providing transport level security.
Server side secure connections utilizes three parameters in the [Parameters] section of the virtuoso.ini:
These parameters should be all set in order to enable the SSL CLI server.
If SSLServerPort is not specified, then the Virtuoso server ignores the other two and does not listen for SSL CLI connections.
If a non-SSL connection is attempted to the SSL server port, the server rejects the connection. If an SSL connection is attempted against the non-SSL port the server rejects the connection.
The client does not require any SSL-specific files (like Certificates or Private keys) in the SSL connection process.
There is an custom ODBC connect option SQL_ENCRYPT_CONNECTION (=5004) supported by the Virtuoso CLI. It should be set before issuing the SQLConnect call. Values are 'NULL' (no encryption - default), '1' (encryption with no server X509 certificate checking and no X509 certificate sent to the server) and a valid file path to a PKCS#12 certificate file (protected with the same password as the one used to log in. Note that with the iODBC/ODBC clients this connect option is not applicable since the driver managers don't cache or pass through the custom ConnectOptions set before connecting to the data source. The ISQL has an additional option (-E) to do encrypted connects using the encryption option '1') and -X <file> to set the above option to the file supplied.
The drivers support an additional DSN attribute:
ENCRYPT=<string>
If this attribute is not specified then it defaults to "No".
It has the same meaning as the SQL_ENCRYPT_CONNECTION options (see above). If this is not specified then it defaults to NULL.
The corresponding iODBC odbc.ini & ODBC Registry DSN attribute name is:
"Encrypt"= <string>
The Windows Connect & Setup dialogs have an additional wizard page to configure encryption.
Virtuoso supports X509 certificate validation: server side for both ODBC and HTTPS connections, and client side for the ODBC connections.
To enable this option there are three new INI file parameters added the HTTPServer section for the HTTPS, and the Parameters section for ODBC):
In order for verification of the server certificate to take place a PKCS#12 file should be supplied to the ODBC client. It will use the CA list in this PKCS#12 to verify the server certificate. It will set the verification depth to -1 (unlimited) while performing such a check.
If the server certificate is not verified correctly it will refuse to connect to the server. When the ENCRYPT parameter is set to "1" (do SSL without X509 validation) the client will return a SQL_SUCCESS_WITH_INFO in SQLConnect/SQLDriverConnect with the Server's certificate subject and the verification result as the server will always send it's X509 certificate to the client as a part of the SSL connect handshake.
If the PKCS#12 file is supplied the ODBC client will try to open it using the login password. In order for the file to be successfully opened it should be encrypted with the same password used for logging in.
Normally when exporting a PKCS#12 file from other programs it will contain only the CAs of the Certificate validation chain. This means that client and server certificates should have common CA in their certificate chains in order to be used for ODBC X509 validation. The client certificate from the PKCS#12 file will not take place in the server certificate validation process.
Access Control Lists (ACL) are used to restrict file system access.
These lists are maintained in the Virtuoso INI file under the Parameters section with entries such as:
DirsAllowed = <path> [, <path>] DirsDenied = <path> [, <path>] <path> := <absolute_path> or <relative_path>
A relative path is relative to the servers current working directory.
ACL's work in the following way:
The following functions are restricted by file Access Control Lists (ACL) in the virtuoso.ini file:
the cfg_write function has restrictions against changing file access control lists in ini file
Previous
Contents of Server Administration |
Chapter Contents |
Next
Virtual Database |