6.1.1. Database

See details for Installation Requirements , Operational Requirements , Operating System Support and Limits .

Server Instance Creation

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.

Installing Application Packages

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.

Server Licensing

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.

Server Logging - Detecting Errors

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.

Configuring Server Startup Files

Virtuoso Configuration File

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.

  • [Flags] Settings for options that are generally used with __dbf_set as temporally valid ( such as enable_joins_only), to be set as permanent.

  • [SPARQL] Settings in this optional section control SPARQL protocol endpoint default parameters and limits.

  • [I18N] encoding settings

  • [Replication] The replication section sets the transactional replication parameters for the server.

  • [Mono] The Mono section contains settings for 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

  • DatabaseFile=virtuoso.db.  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.

  • TransactionFile=virtuoso.trx.  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.

  • ErrorLogFile=virtuoso.log.  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.

  • ErrorLogLevel=7.  This controls what events get logged into the database error log. This should always be 7.

  • LockFile=virtuoso.lck.  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.

  • FileExtend=100.  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.

  • Striping=0.  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.

  • LogSegments.  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=...

  • Log1=/tmp/log1.trx 100M.  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.

  • crashdump_start_dp, crashdump_end_dp.  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.

  • TempStorage = <TempDatabase_Name>.  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.

  • Syslog = 1/0 (default 0).  Virtuoso can 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 enabled using this option, by default it is set to 0 meaning off.

    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.

  • DatabaseFile = <database file name>.tdb.  Name of temporary database file.

  • TransactionFile = <transaction file name>.ttr.  Name of temporary transaction file.

  • FileExtend = NNN.  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.

  • SingleCPU=0.  This is a Win32 specific option that forces Virtuoso to only run on one CPU in a multiprocessor environment.

  • ServerPort=[<IP Address>]:<port>.  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.

  • ServerThreads=10.  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.

  • ServerThreadSize=50000.  Stack size of thread used for reading client messages and accepting connections.(default : 50 000 bytes)

  • MainThreadSize=100000.  Stack size of the main thread (default : 100 000 bytes)

  • ThreadCleanupInterval.  The interval in minutes (default : 0) after which threads in the thread pool should be released.

  • ThreadThreshold.  The maximum number of threads (default : 10) to leave in the thread queue after thread clean-up interval has expired.

  • SchedulerInterval.  Defines the scheduler wake-up interval ( in minutes). By default is 0 i.e. the scheduler is disabled.

  • ResourcesCleanupInterval.  The interval in minutes (default : 0) after which allocated resources will be flushed..

  • FutureThreadSize=100000.  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)

  • TempAllocationPct.  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.

  • O_DIRECT.  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 I/O 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.

  • CheckpointInterval=60.  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.

  • CheckpointSyncMode=2.  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.

  • PageMapCheck=0.  This controls the check of page maps:

    0. - disables the check of page maps.

    1. - enables the check of page maps.

  • NumberOfBuffers=2000.  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.

  • MaxCheckpointRemap=2000.  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.

  • PrefixResultNames=0.  This setting should always be 0.

  • CaseMode=1.  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.

    [Note] Note:

    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.

  • MinAutoCheckpointSize=4000000.  See CheckpointInterval.

  • AutoCheckpointLogSize.  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.

  • CheckpointAuditTrail=1.  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.

  • AllowOSCalls=0.  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.

  • MaxStaticCursorRows=5000.  This is the maximum number of rows returned by a static cursor. Default = 5000

  • FreeTextBatchSize=10000000.  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

  • NullUnspecifiedParams.  When set to 1, if an application prepares a statement with insufficient number of input parameters, the unspecified ones are assumed to be NULL.

  • Collation.  Defines a sorting order according to SYS_COLLATIONS. The name supplied to this parameter must be in charsets_list(1) .

  • DirsAllowed=<path> [, <path>].  <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. On Windows use in the path "\".

    SQL> select server_root (), virtuoso_ini_path ();

    SQL> select cfg_item_value (virtuoso_ini_path (), 'Parameters',

    The Virtuoso ISQL utility can be used to check the Server DirsAllowed params as follows:

    The above should show in the result the server working directory and INI file name.

    Also you can check the relevant INI setting by running following statement via ISQL command line utility:

  • DirsDenied=<path> [, <path>].  <path> := <absolute_path> or <relative_path> OS directories denied for file operations. See Virtuoso ACL's for information on functions that are restricted.

  • VADInstallDir=<path>.  <path> := <absolute_path> or <relative_path> OS directory containig VADs files. When set, enables automatic update of vads on server startup. On Windows use in the path "\".

  • SSLServerPort.  Specifies the port on which the server listens for incoming SSL CLI requests.

  • SSLCertificate.  The SSL certificate to use (same meaning as the SSLCertificate in HTTPServer section)

  • SSLPrivateKey.  The server's private key (same meaning as the SSLCertificate in HTTPServer section)

  • MaxOptimizeLayouts = 1000.  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.

  • StopCompilerWhenXOverRunTime = 0.  The default value is 0. If non-zero, this specifies that the SQL compiler should stop considering alternative execution plans after the elapsed compilation time exceeds the best run time estimate times the parameter. For example, if this is 2, then compilation stops after using twice the time of the best plan reached thus far. Enabling this option increases performance when processing short running queries that are each executed once. Using this with long running queries or prepared parametrized queries is not useful and may lead to non-optimal plans being selected.

  • TraceOn = option1 [, option2 [, ..]].  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:


    [Tip] See Also:

    The functions: trace_on() and trace_off() which use the same options and can turn logging options on/off while the server is running.

    Example 6.1. Using the TraceOn ini file option

    TraceOn = soap, errors

    This will enable logging of additional information regarding SOAP calls and SQL run-time errors into the virtuoso.log file.

    Example 6.2. Using the ThreadCleanupInterval and ResourcesCleanupInterval ini file option

    ThreadCleanupInterval    = 1
    ResourcesCleanupInterval = 1

    Set both to 1 in order to clean up unused threads/resources and reduce memory consumption of the Virtuoso server, which can otherwise be construed as memory leaks.

    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.

  • AllowPasswordEncryption = 1/0.  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.

  • JavaClasspath.  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:

    The java_vm_create VSE parameter list
    This "JavaClasspath" in [Parameters] INI section
    The CLASSPATH environment variable
    If none of the above the CLASSPATH is the current directory.
  • JavaVMOption1..N = <opts>.  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
  • PLDebug = 0.  The PLDebug switch controls the type of debugging enabled:

    PLDebug = 0 - default debugging information and test coverage disabled.
    PLDebug = 1 - debugging information enabled.
    PLDebug = 2 - debugging information enabled, test coverage data will be written to file specified in TestCoverage Virtuoso ini file parameter.
  • TestCoverage = cov.xml. 

  • CallstackOnException = 0.  Controls whether Virtuoso will report call stack on errors.

    This parameters takes the following values:

    0 (default) - Call stack reporting disabled.
    1 - Call stack reporting enabled.
  • CompileProceduresOnStartup = 1.  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.

  • FDsPerFile = 1.  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 I/O operations may simultaneously be pending per file. This allows more flexibility for the OS to schedule the operations, potentially improving file I/O throughput

  • RecursiveFreeTextUsage = 1/0 default 1.  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.

  • RecursiveTriggerCalls = 1/0 default 1.  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.

  • MaxSortedTopRows = 10000.  The TOP select statement clause caches in memory the rows pertinent to the result. The number of rows allowed to be cached within memory is limited by this parameter.

    Simple example using OFFSET and LIMIT:

    Virtuoso uses a zero index in the OFFSET. Thus in the example below, will be taken position at record 9000 in the result set, and will get the next 1000 rows starting from 9001 record. Note that the MaxSortedTopRows in parameters Virtuoso ini section needs to be increased (default is 10000).

    select ?name
    ORDER BY ?name
    OFFSET 9000
    LIMIT 1000
  • DisableUnixSocket = 0/1 default 0.  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.

  • TransactionAfterImageLimit = N bytes default 50000000.  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 which is 50Mb the total transient consumption is closer to 150 Mb.

  • TempSesDir.  Directory for storing temporary data for large object handled in replication and HTTP server. Defaults to server home directory.

  • DbevEnable = 0/1 default 1.  Enable or disable Database Event Hooks .

  • RunAs.  Specifies the OS user name to which the server will switch after opening the listen ports. Has an effect only on the operating systems that support it.

  • MaxMemPoolSize = 200000000.  This parameter 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 applied. The default is 200000000. 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.

  • DefaultIsolation.  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.

  • UseAIO.  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.

  • TempDBSize.  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.

  • LiteMode = 0/1 (default 0).  Runs server in lite mode. When Lite mode is on:

    • the web services are not initialized i.e. no web server, dav, soap, pop3 etc.

    • the replication is stopped

    • the pl debugging is disabled

    • plugins are disabled

    • rendezvous is disabled

    • the relevant tables to the above are not created

    • the index tree maps is set to 8 if no other setting is given

    • memory reserve is not allocated

    • affects DisableTcpSocket. So DisableTcpSocket setting is treated as 1 when LiteMode=1, regardless of value in INI file

  • RdfFreeTextRulesSize = 10 or more.  The size of hash to control rdf free text index

  • IndexTreeMaps = 2 -1024 (power of 2).  Size of index tree maps, larger is better for speed but consume memory, in lite is 2 in 'normal' mode is 256 by default.

  • DisableTcpSocket = 1/0.  Default = 0. If set to 1, disables database listener on TCP port; unix socket must be used for data access connections (ODBC, JDBC, ADO.NET, OLE DB). When LiteMode=1, DisableTcpSocket setting in INI file is ignored and treated as if set to 1.

  • ExtentReadThreshold.  Controls speculative read of disk pages. If pages are read in close succession from an extent of 256 consecutive pages, the system may decide to speculatively read the entire extent.

    ExtentReadThreshold parameter gives how many consecutive reads are needed to trigger this.

    When is set to 0, this means that anytime a page is read, the whole extent is read along with it

    When is set to 1, this means that if the first read is at time t and the next one at time t1 and t1-t < ini_ExtentReadWindow msec, then 2nd read triggers the speculative read.

    Default is 2.

    Takes effect after the buffer pool is full.

  • ExtentReadWindow.  Controls speculative read of disk pages. If pages are read in close succession from an extent of 256 consecutive pages, the system may decide to speculatively read the entire extent.

    ExtentReadWindow parameter gives the time within which the reads must fall.

    Default is 1000.

    Takes effect after the buffer pool is full.

  • ExtentReadStartupThreshold.  Controls speculative read of disk pages. If pages are read in close succession from an extent of 256 consecutive pages, the system may decide to speculatively read the entire extent.

    ExtentReadStartupThreshold parameter value applies while the server is freshly started and the buffer pool is not yet full. It can be set to preread more aggressively.

    Default is 0.

  • ExtentReadStartupWindow.  Controls speculative read of disk pages. If pages are read in close succession from an extent of 256 consecutive pages, the system may decide to speculatively read the entire extent.

    ExtentReadStartupWindow parameter value applies while the server is freshly started and the buffer pool is not yet full. It can be set to preread more aggressively.

    Default is 40000.

  • ColumnStore.  If 1, all create table and create index statements will create column-store structures by default.

    Note: Only effective with Virtuoso 7.0 and later.

  • AsyncQueueMaxThreads.  Sets the number of threads in a pool that is used for getting extra threads for running queries and for aq_request. Each running statement has at least one thread that is not allocated from this pool plus zero or more threads from this pool.

    Setting the pool size to the number of cores plus a few is a reasonable default. On platforms with core multithreading, one can count a core thread as a core for purposes of this parameter.

    If one expects to run many slow aq_requests() (see async_queue() , aq_request() , etc.), then the number of threads should be increased by the number of slow threads one expects.

    Slow threads are typically I/O bound threads used for web crawling or similar long-latency, low-CPU activity.

    Note: Only effective with Virtuoso 7.0 and later.

  • ThreadsPerQuery.  This is maximum number of threads that can be claimed from the thread pool by a single query. A value of one means that no query parallelization will take place, and all queries will run single threaded.

    The number of cores on the machine is a reasonable default if running large queries.

    Note that since every query is served by at least one thread, a single query taking all the extra threads will not prevent other queries from progressing.

    Note: Only effective with Virtuoso 7.0 and later.

  • VectorSize.  This the number of simultaneous sets of query variable bindings processed at one time. The default is 10,000, which is good for most cases.

    FROM t1 a,
         t1 b
    WHERE a.row_no + 1 = b.row_no

    If we are evaluating the query:

    with vector size of 10,000, then 10,000 rows of t1 a will be fetched first; 1 will be added to the 10,000 row_no values; and then the corresponding row of t1 b will be fetched for the 10,000 row_no of t1 a. This process will repeat until enough batches of t1 a have been fetched to come to its end.

    Note: Only effective with Virtuoso 7.0 and later.

  • AdjustVectorSize.  Using a larger vector size when evaluating large queries with indexed random-access can yield up to a 3x speed-up relative to using the default vector size. However, always using a large vector size will prohibitively increase the overhead of running small queries. For this reason, there is the option to adaptively select the vector size. Set AdjustVectorSize = 1 to enable this feature. The SQL execution engine will increase the vector size when it sees an index lookup that does not get good locality, (e.g., after sorting the keys to look for, too few consecutive lookups fall on the same page). Having more keys to look up increases the chance that consecutive keys should be found on the same page, thus eliminating much of the index lookup cost.

    Note: Only effective with Virtuoso 7.0 and later.

  • MaxQueryMem.  This controls the maximum amount of memory that can be used across the server process for large vectors, i.e. if the memory in use is near this limit, a query will not switch to large vector size even if it finds it useful. The event counter tc_no_mem_for_longer_batch counts how many times this situation is detected. A size letter of G or M follows the value.

    Note: Only effective with Virtuoso 7.0 and later.

  • HashJoinSpace.  This controls the maximum amount of memory that can be used across the server process for hash join hash tables. This is followed by a size letter M or G. A single hash join hash table will only claim a percentage of the remaining hash join space, by default 50. This is controlled by the chash_per_query_pct setting, see section on vectored execution tuning. If there is not enough memory, a partitioned hash join will be used, making as many passes over the data as needed so that the hash table will fit within the set limits.

    Note: Only effective with Virtuoso 7.0 and later.

  • MaxVectorSize.  When AdjustVectorSize is on, this setting gives the maximum vector size. The default is 1,000,000 and the largest allowed value is about 3,500,000.

    Note: Only effective with Virtuoso 7.0 and later.

  • TimezonelessDatetimes.  Enables Timezoneless Support. Different applications may require different behavior when input data contain timezoneless values. In some cases it is better to "cast" all of them to timezoned than to upgrade existing code. Virtuoso offers 5 different modes of support -- 0, 1, 2, 3 and 4. This should be set before creating the database and the set value is stored in the database. After database is created, an attempt to change the mode by patching virtuoso.ini will have no effect and virtuoso.log will contain a warning about mismatch between virtuoso.ini and the database file.

    • TimezonelessDatetimes=0 -- Never use timezoneless, as it was in old databases. Always set local timezone on parsing strings if no timezone specified. An attempt to set timezoneless by calling function forget_timezone() will signal error. Timezoneless values still may come from outside as dezerializations of timezoneless DATETIME values, serialized by other database instances, but not in any other way:

    • TimezonelessDatetimes=1 -- When parsing strings, set timezoneless if ISO format tells so:

    • TimezonelessDatetimes=2 -- Set timezoneless always, exception is when the parsed string contains explicit timezone or when RFC requires the use of GMT or when timezone is set by function adjust_timezone() . This is default for new databases if TimezonelessDatetimes parameter is missing in virtuoso.ini

    • TimezonelessDatetimes=3 -- Never use timezoneless. Always set local timezone on parsing strings if not timezone specified. An attempt to set timezoneless by calling function forget_timezone() will signal error. Timezoneless values still may come from outside as deserializations of timezoneless DATETIME values, serialized by other database instances, but not in any other way. The difference with TimezonelessDatetimes=0 is that timezones are always printed on cast datetimes to strings etc. so timezoneless-aware clients will get unambiguous data.

    • TimezonelessDatetimes=4 -- On parsing string, set timezone to GMT if no timezone specified. However, timezoneless can be set by calling function forget_timezone() . This mode can be convenient for global web services when real "local" timezones of specific users are not known.

    The possible variants are:

    For new applications, consider the use of TimezonelessDatetimes=2 as primary variant, TimezonelessDatetimes=1 as the second best.

Note: The default for startup behavior is to always read full extents and the default for the normal behavior is to trigger preread on the third read inside one second.


Settings in this section control the web server component of the Virtuoso Server.

  • ServerPort.  This specifies the initial HTTP listen port for the HTTP server. Can be specified also as ipaddress:port. Once Virtuoso is started it is possible to create multiple listeners using virtual directories.

  • HTTPThreadSize = 120000.  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.

  • ServerThreads.  This specifies the number of concurrently serviced HTTP requests. Its alias is MaxClientConnections . 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.

  • HTTPThreadSize = 120000.  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.

  • ServerRoot = ../vsp.  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.

  • ServerIdString = Virtuoso.  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.

  • ClientIdString = Mozilla/4.0 (compatible; Virtuoso).  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.

  • Charset = [CHARSET-NAME].  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.

  • EnabledGzipContent = 0.  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.

  • MaxKeepAlives = 10.  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.

  • KeepAliveTimeout = 10.  This is a timeout in seconds before Virtuoso closes an idle HTTP 1.1 connection.

  • HTTPProxyEnabled = 0.  Setting this to 1 activates Virtuoso proxy service capabilities. The default value of 0 deactivates the proxy service.

    [Note] Note:

    Ports on which proxying is enabled should not be presented to the outside world under any situation.

  • HTTPProxyServer = proxylocal:3128.  HTTP proxy server name and port

  • HTTPProxyExceptions = localhost:8890,  HTTP proxy exceptions name and port.

  • HTTPLogFile = log.out.  If specified, Virtuoso will produce an HTTP server log file with the date appended to the name given in the parameter and the files extension as ".out". The log file is rotated daily.

    It will contain the following information:

    logDDMMYYYY.out :-

    Client IP address
    Date and time of request/response
    Timestamp (milliseconds)
    Request/response line

    An example of which is:

     - - [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: Gecko.."
     - - [12/Sep/2006:12:31:18 +0300] "GET /ods/default.css HTTP/1.1" 200 41389 "http://example.com/ods/" "Mozilla/5.0 (Windows; U; ..."
     - - [12/Sep/2006:12:31:19 +0300] "GET /ods/common.js HTTP/1.1" 200 7481 "http://example.com/ods/" "Mozilla/5.0 (Windows; U; ..."
  • HTTPLogFormat = format string like apache mod_log.  "HTTPLogFormat" INI file param works in conjunction with the "HTTPLogFile" INI file param. In http log we support format string like Apache Module mod_log_config . For example:

    HTTPLogFormat = %h %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i" "%{NetId}e"

    In this example we have %{User-Agent}i which means to log the HTTP header for user-agent. In similar way can log other input headers, "e" modifier is for environment variable NetId in this case.

    Note that not all escapes from Apache Module mod_log_config are supported.

  • MaxCachedProxyConnections = 10.  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.

  • ProxyConnectionCacheTimeout = 15.  This is a timeout in seconds for dropping idle connections to other HTTP servers. These result from http_get, SOAP client functions and proxying.

  • DavRoot = DAV.  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.

  • DAVQuotaEnabled = 1/0.  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.

  • DAVChunkedQuota = 1000000.  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.

  • SSLPort=4433.  this is the port on which SSL HTTPS connections will be accepted. Can be specified also as ipaddress:port. If unspecified then the service will be disabled.

  • SSLCertificate=./virtuoso_cert.pem.  the option must point to the file with the server certificate in PEM format.

    If the option begins with 'db:' e.g. 'db:id_server', then certificate and key will be loaded from DBA key space.

  • SSLPrivateKey=./virtuoso_key.pem.  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)

    If the option begins with 'db:' e.g. 'db:id_server', then certificate and key will be loaded from DBA key space. Note: in the case of database stored key, both SSLCertificate and SSLPrivateKey settings MUST be same.

  • X509ClientVerify=0.  Whether the server will require X509 certificates from the browsers.

    X509ClientVerify = 0 - no certificate verification required
    X509ClientVerify = 1 - ask for trusted certificates
    X509ClientVerify = 2 - optionally ask for trusted certificates, if trusted certificate is presented it will be verified
    X509ClientVerify = 3 - optionally accept any certificate including self-signed certificates
  • X509ClientVerifyDepth=1.  Specifies how deep the client certificate verification process will traverse the Issuer chain before giving up. The default value of 0 means that only verification of the client certificate itself being in the server's CA list is performed. Setting this option to -1 will ignore the depth checks

  • X509ClientVerifyCAFile=./calist.pem.  a PEM file of all the X509 certificates of the Certification Authorities (CA) which the server will use for verifying the client's client certificate. A list of these will be sent to the client as a part of the SSL handshake so the client will know which certificate to send.

    Note this option is in effect when X509ClientVerify is 1 or 2. If X509ClientVerify is 3 and X509ClientVerifyCAFile is given, server will send certificated during handshake, thus some clients may restrict user to send any certificate.

  • POP3Port=1234.  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.

  • NewsServerPort=1235.  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.

  • FTPServerPort.  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.

  • FTPServerMinFreePort = 20000.  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.

  • FTPServerMaxFreePort = 30000.  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.

  • FTPServerLogFile = ftpserver.  If specified Virtuoso will produce an FTP server log file with the date appended to the name given in the parameter and the files extension as ".log". The log file is rotated daily.

    It will contain the following information:

    ftpserverDDMMYYYY.log :-

    Client Host Name
    Authorized User
    User Command
    Server Response Code
    Bytes Transferred

    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
  • FTPServerAnonymousLogin = 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.

  • DefaultMailServer=localhost:25.  Default SMTP server name and port, this is used when the first parameter of the smtp_send function is omitted or NULL.

  • TempASPXDir.  Allows you to choose what file system directory to be used for temporary storage of ASPX files hosted in DAV.

  • PersistentHostingModules = [1/]0.  When set to "1" prevents Virtuoso from removing the plugin interpreters from the HTTP threads after each request. The default setting is "0".

  • HttpSessionSize = size in bytes, default 10000000.  The size threshold for large objects received 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.

  • MaintenancePage = file_name.  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.


  • enable_joins_only = 0.  Setting enable_joins_only will cause the optimizer to only consider next plan candidates that are connected by a join to the existing partial plan. In other words, no cartesian products will be considered. This may save some space and time.


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.

  • DefaultHost = canonical name of the server, used by default for metadata retrieval, no default value.  The server name, including domain and port if needed, such as "www.example.com" or "www.example.com:8088".

  • LocalHostNames = comma-delimited list of names of the server, that can be used for retrieval of metadata, no default value.  List of various allowed spellings of the server name, such as "www.example.com, mail.example.com, mail, localhost, localhost.localdomain".

  • LocalHostMasks = comma-delimited list of name masks of the server, no default value.  List of various allowed spellings of the server name in form of pattern strings for SQL "like" operator, not in form of exact strings.

  • Fingerprint = unique fingerprint string of the server or group of identical servers, no default value.  Do not use this without an explicit need, to let server configure itself. Please refer to detailed description before use.

  • DynamicLocal = 1/0 default 0, allow dynamic hostname translation in the IRIs.  If DynamicLocal is on and the host part of the IRI matches the Host header of the HTTP request in context or the DefaultHost if outside of HTTP context, then this is replaced with local: before looking up the IRI ID.


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 Data Access and Data Management contains detailed description of this functionality.

  • ExternalQuerySource = 1 or 0 .  This controls processing of the "query-uri" parameter of the SPARQL query protocol webservice, means enable 1 or prohibited 0.

  • MinExpiration = 86400 .  Sponger caching parameter in seconds. It will cause sponger to use this value as minimal expiration of the pages, which would help in cases where source document's server do not report expiration or it reports no caching at all.

  • MaxCacheExpiration = 1 .  Cache Expiration time in seconds that overrides Sponger's default cache invalidation.

  • MaxDataSourceSize = 20971520 .  Controls the max size that can be sponged. Default is 20 MB.

  • ExternalXsltSource = 1 or 0 .  This controls processing of the "xslt-uri" parameter of the SPARQL query protocol webservice, means enable 1 or prohibited 0.

  • ResultSetMaxRows = number .  This setting is used to limit the number of the rows in the result. The effective limit will be the lowest of this setting, SPARQL query 'LIMIT' clause value (if present), and SPARQL Endpoint request URI &maxrows parameter value (if present).

  • DefaultGraph = IRI .  IRI of the default graph to be used if no "default-graph-uri" parameter is specified.

  • MaxQueryCostEstimationTime = seconds .  This setting is used to limit the estimate time cost of the query to certain number of seconds, the default is no limit.

  • MaxQueryExecutionTime = seconds .  This setting is used to set the transaction execution timeout to certain limit in number of seconds, the default is no limit.

  • ImmutableGraphs = URI .  IRI of graphs over which the sponger not to be able able to write.

  • PingService = URI .  IRI of notification service to which the sponger results will be send.

  • DefaultQuery = SPARQL Query .  Default SPARQL Query.

  • DeferInferenceRulesInit = 1 .  Defer Loading of inference rules at start up.

  • ShortenLongURIs = 1 .  Shorten extremely long URIs in datasets when loading with the RDF Bulk Loader. Default is 0.

    Note : This parameter is only in the Virtuoso 06.03.3131+ commercial builds, at the time of writing it is not included in the open source 6.1.4 archives but will be in the next 6.1.5 release. A patch to enable this feature is however available from the Virtuso patches page on source forge , which can be applied to a 6.1.4 archive from source forge and the Virtuoso server binary rebuilt.

  • MaxMemInUse = 0 .  Maximum amount of memory that is allowed for temporary storing parts of a SPARQL query result. Default is zero for no limit. ResultSetMaxRows is maximum length of a SPARQL query result. Default is zero for no limit. These two options may be useful for protecting public web service endpoints against DOS attacks, but at the same time it may cause returning incomplete results without reporting errors. When used, it is strongly advised to set the value orders of magnitude larger than the expected size of longest reply. As a rule of thumb, timeout should happen before this limit has reached. Values less than 1000000 bytes are impractical in all cases.

The SPARQL INI can be get as RDF via http://cname/sparql?ini service.

  • WideFileNames = 1/2/3/0.  0: default value. It means not to normalize anything, so for ex. "José" and "Jose" are two distinct words.


    1: Any pair of base char and combinig char (NSM, non-spacing modifier) is replaced with a single combined char, so if character "é" is written as a sequence of "base" character "e" and a unicode char U +301 ("combining acute accent") then the pair will be replaced with single U+00E9 ("latin small letter e acute").

    2: Any combined char is converted to its (smallest known) base. So "é" will lose its accent and become plain old ASCII "e".

    3: This is equl to 1|2 and when set then performs both conversions. As a result, pair of base char and combinig char loses its second char and chars with accents will lose accents.

    If the parameter is required at all, the needed value is probably 3. So the fragment of virtuoso.ini should be:

  • WideFileNames = 1/0.  Default is 0. When 1 then file access and directory listing functions may use wide strings as file names. If a file name contains non-ASCII characters then directory listing result set will contain a wide string instead of narrow string with question marks. Note, however, that most of existing applications do not support wide strings for that purposes, so the feature should be used with extreme care.

  • VolumeEncoding.  Encoding identifier. If set, file names are translated from wide strings and default server encoding to the specified encoding before using them in file manipulation BIFs. This is useful when server's filesystem is in some national encoding or in UTF-8. The translation is bi-directional: directory listing items are translated from volume encoding to the default server encoding or wide.

  • VolumeEmergencyEncoding.  Encoding identifier. If set, this encoding is used when the use of VolumeEncoding causes encoding errors. The most popular case is when an UNIX filesystem tree with UTF-8 contains some mounts of legacy storages with KOI or CP encoding. Less popular is UTF-8 volume encoding and UTF-8QR as emergency encoding to recover poorly encoded filenames.

  • VolumeEmergencyEncodingDirs.  List of directories in same syntax as DirsAllowed, default is empty. If set, all file names in the listed directories are supposed to be in VolumeEmergencyEncoding and VolumeEncoding is even not tried. The most popular case is when an UNIX filesystem tree with UTF-8 contains some mounts of legacy storages with KOI or CP encoding.


The replication section sets the transactional replication parameters for the server.

  • ServerEnable=0/1.  A boolean parameter controlling whether a Virtuoso can or cannot act as a transactional replication publisher.

  • ServerName = log1.  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.

  • QueueMax = 50000.  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.

  • MONO_ROOT.  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.

  • MONO_PATH.  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.

  • MONO_CFG_DIR.  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.

  • virtclr.dll.  A fully qualified path and filename of the virtclr.dll virtuoso helper assembly.

  • MONO_TRACE = Off.  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.

  • SQL_QUERY_TIMEOUT=0.  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.

  • SQL_TXN_TIMEOUT=0.  This is an ODBC extension option allowing setting a maximum duration for a transaction. 0 means that there is no maximum.

  • SQL_PREFETCH_ROWS=100.  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.

  • SQL_PREFETCH_BYTES=16000.  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.

  • SQL_NO_CHAR_C_ESCAPE=0.  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.

  • SQL_UTF8_EXECS = 0.  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

  • SQL_BINARY_TIMESTAMP = 1.  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

  • SQL_NO_SYSTEM_TABLES = 0.  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.

  • ArrayOptimization=0/1.  Boolean parameter which allows the Virtuoso VDB to use Array parameters if the remote data source supports these.

  • UseMTS = 0.  This parameter turns on/off MTS support in Virtuoso. It is applicable to windows multithreaded version of the Virtuoso server only.

  • NumArrayParameters.  Specifies a size of the parameter batch used by the VDB (default = 10)

  • VDBDisconnectTimeout.  The time (in seconds) after which a VDB connection is considered timed-out and closed. Default : 1000

  • VDBOracleCatalogFix=0/1.  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.

  • AttachInAutoCommit.  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).

  • NumArrayParameters=10. 

  • ReconnectOnFailure=0 [1|0].  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.

  • KeepConnectionOnFixedThread=1 [0|1|2|4|8].  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' elapses between ending the last and receiving 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 coming 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 cancellation requests can be processed.

    To disable ever going to burst mode, this option can be set to 2

  • PrpcBurstTimeoutMsecs=100 (milliseconds).  RPC burst mode timeout in milliseconds. (see above)

  • SerializeConnect=0 [1|0].  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..

  • SkipDMLPrimaryKey=0 [1|0].  This setting controls 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.

  • RemotePKNotUnique=0 [1|0].  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.

  • UseGlobalPool=0 [1|0].  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.

  • UcmPath.  String parameter which specifies the path where UCM files are located. If this parameter is not specified, UCM files cannot be loaded.

  • Ucm1, Ucm2,... Ucm99.  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.

[Zero Config]
  • ServerName.  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.

  • ServerDSN.  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.

  • SSLServerName.  Name used to advertise the Virtuoso ODBC SSL encrypted service details in ZeroConfig.

  • SSLServerDSN.  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.

[Tip] See Also:

The Zero Config section.

  • LoadPath = /home/virtuoso/hosting.  The directory containing shared objects/libraries for use as Virtuoso VSEI plugins.

  • Load<number> = <module type>, <module name>.  <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 "Hosting" and "attach" types exist. <module name> is the file name of the modules shared library or object.


    Load6 = attach, libphp5.so )

    Load7 = Hosting, hosting_php.so )

    "Attach" is used for now for the php library. It can be used to load other libraries in future too. The reason is to load PHP5 functionality into virtuoso namespace, so when actually is loaded the hosting plugin, it can bind to the already available symbols for php5.

[Tip] See Also:

VSEI Plugins

  • Segment<number> = <size>, <stripe file name> [, <stripe file name> .. ].  <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.

[Note] Note:

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 temporary 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.

[Tip] See Also:

Rebuilding A Database in the Backup section.

Sample Configuration File ("virtuoso.ini")

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
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
ServerPort         	= 1111
ServerThreads      	= 10
CheckpointInterval 	= 60
CheckpointSync 		= 2
NumberOfBuffers    	= 2000
MaxDirtyBuffers    	= 1200
MaxCheckpointRemap 	= 2000
PrefixResultNames	= 0
CaseMode           	= 1
;MinAutoCheckpointSize	= 4000000
AutoCheckpointLogSize	= 40000000
CheckpointAuditTrail		= 1

ServerPort = 1122
ServerRoot = ../vsp
ServerThreads = 2
MaxKeepAlives = 10
KeepAliveTimeout = 10
MaxCachedProxyConnections = 10
ProxyConnectionCacheTimeout = 15
DavRoot = DAV

ServerName = log1
Server = 1
QueueMax = 50000


BadParentLinks	    = 0
BadDTP			        = 0

;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.
Segment1	= 100M, db-seg1-1.db, db-seg1-2.db
Segment2	= 100M, db-seg2-1.db
Configuring Vectored Execution

Note: Only effective with Virtuoso 7.0 and later.

A Virtuoso 7 executable executes all SQL statements in vectored mode, except for positioned updates and deletes in stored procedures. Procedures are executed without vectoring unless they are declared vectored using the vectored keyword. A scalar (non-vectored) procedure can have a vectored block introduced with the for vectored construct. These are discussed in the SQL reference section on vectoring.

Vectored execution is controlled by the following virtuoso.ini settings:

  • VectorSize = 10000

    : This is the default number of concurrent variable bindings that are generated for a column in a batch of bindings.

  • MaxQueryMem = 1G

    : This controls the maximum amount of memory that can be used across the server process for large vectors, i.e. if the memory in use is near this limit, a query will not switch to large vector size even if it finds it useful. The event counter tc_no_mem_for_longer_batch counts how many times this situation is detected. A size letter of G or M follows the value.

  • AdjustVectorSize = 1

    : If non-zero, this enables automatic increasing of vector size whenever the system notices a random access pattern that is not benefiting from vectoring due to too few consecutive hits falling on the same page. The vector size can be increased up to MaxVectorSize if the situation warrants. This is the case if there is enough unprocessed state in the query.

  • MaxVectorSize = 1000000

    : This is the maximum vector size. This can reach up to 4000000 but values in excess of 1000000 have not been found useful in practice. If the server is running out of memory with multiuser workloads involving long queries, dropping the MaxVectorSize to a lower value is a means of curtailing per query memory consumption.

  • ThreadsPerQuery = 8

    : This controls the maximum number of parallelizable work units a query will have outstanding at any one time. A value of 8 means that a scan or vector of lookups is maximally divided into 8 units, of which 7 will be allocated to a pool of worker threads and one will be processed by the thread coordinating the query. Each query will always have one thread running, which is the thread allocated for serving the client-server or HTTP request initiating the query. Extra work units are serviced by threads from a parallel execution thread pool. If there are unstarted parallel work units that have not started at the time the coordinated thread finishes its own work unit, it will execute any of its own pending work units locally.

  • AsyncQueueMaxThreads = 16

    : This is the maximum number of worker threads that can be started for running parallelized work units generated by queries or functions requested with the aq_request () PL function. Thus the number of threads running on a server at any time is the number of client server or HTTP threads that have a running request plus this number. These threads consider the totality of all async execution requests across all async queues and each thread picks a unit of work from the oldest queue that has unstarted work units. The age of the queue is the timestamp of its creation. A queue is created whenever a query operator decides to split its work. This scheduling favors thus old queries over new ones. However any request is guaranteed one thread, that on which its initiating request is served.

    For a query processing workload, one should set AsyncQueueMaxThreads to the number of cores minus the expected number of concurrent queries, this would in principle use all cores or core threads. In practice for machines with large numbers of cores, e.g. 32 cores, a lower value may serve in practice better, subject to experimentation. For a web crawling situation where threads are waiting for the network for most of the time, a larger number will do better.

These parameters can be set at run time by a dba group user using the __dbf_set() function.

Index Defragmentation

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.


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.


-- Compact all tables and indices of the Virtuoso instance
Db..VACUUM ('WS.%');
-- compact all tables of the WS. qualifier
-- compact the rdf_quad_pgos index of the rdf_quad table.

Virtuoso has an autocompact feature.

Server Startup Command Line Options

Virtuoso Server

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:

  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:

  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
  +log6                  If you're starting with a Virtuoso 5 server, and migrating to a Virtuoso 6 or
                         later server, append +log6 after +backup-dump or +crash-dump.
                         Note: The extra +log6 argument is not needed, and may have unexpected effect,
                         so please leave it off if starting with a Virtuoso 6 server and moving to
                         Virtuoso 6 or later.
  +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:

o - only open the database and define the SYS_KEYS, SYS_COLS, SYS_KEY_PARTS, SYS_CHARSETS AND SYS_COLLATIONS system tables.
n - leaves out the initialization of the system tables.
b - do not process anything except the transaction log and system tables when restoring a crash dump (+restore-crash-dump).
a - leaves out the initialization of the replication, users, compilation or stored and system procedures, as well as the caching of the grants.
l - write only the schema tables in the backup or crash dump.
r - don't do the complete initialization (useful for performing a crash dump).

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:

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

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.

[Note] Note:

Make sure the Services Control Panel is closed, before attempting to modify services from the command line, otherwise locking may occur.

ZeroConfig ("Zero Configuration") Support

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:

secure connection options
default database
default user
default password (if public/demo login is required)
default character set

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.

Setting-up the Server for Service Advertising

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)

The ServerName and SSLServerName are human readable strings chosen by the administrator to provide clients with a suitable description of the service being provided.

[Note] Note:

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.

Using the Windows ODBC Driver with ZeroConfig

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.

Server Status Monitoring

The database status report is divided into 6 sections:

Index Usage

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:

File size:  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.

Disk Usage:  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.

The Gate:  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.

Databases.  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 checkpoint space at the next checkpoint. Understanding these is not necessary.

[Tip] See:

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.

Index Usage

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.

Re-labeling Server Executable on Win32 Platforms

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:

stop the service
delete the service
change the name in file virtuoso.ini
create the service
start the service

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.

Transport Level Security


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 Support

Server side secure connections utilizes three parameters in the [Parameters] section of the virtuoso.ini:

SSLServerPort - Specifies the port on which the server listens for incoming SSL CLI requests.
SSLCertificate - The SSL certificate to use (same meaning as the SSLCertificate in HTTPServer section)
SSLPrivateKey - The server's private key (same meaning as the SSLCertificate in HTTPServer section)

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.

Client-side Support

The client does not require any SSL-specific files (like Certificates or Private keys) in the SSL connection process.

Native Clients (e.g. ISQL).  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.

ODBC & iODBC Driver.  The drivers support an additional DSN attribute:


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.

X509 Certificate Support

Virtuoso supports X509 certificate validation: server side for both ODBC and HTTPS connections, and client side for the ODBC connections.

Server Side.  To enable this option there are three new INI file parameters added the HTTPServer section for the HTTPS, and the Parameters section for ODBC):

X509ClientVerify - Whether the server will require X509 certificates from the browsers. If set to 1 a client should send a X509 certificate which will be validated against the server CA list.
X509ClientVerifyDepth - Specifies how deep the client certificate verification process will traverse the Issuer chain before giving up. The default value of 0 means that only verification of the client certificate itself being in the server's CA list is performed. Setting this option to -1 will ignore the depth checks.
X509ClientVerifyCAFile - a PEM (base64) file of all the X509 certificates of the Certification Authorities (CA) which the server will use for verifying the client's client certificate. A list of these will be sent to the client as a part of the SSL handshake so the client will know which certificate to send.

ODBC Client Side.  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.

File System Access Control Lists

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>
[Note] Note:

A relative path is relative to the servers current working directory.

The Virtuoso ISQL utility can be used to check the Server DirsAllowed params as follows:

SQL> select server_root (), virtuoso_ini_path ();

The above should show in the result the server working directory and INI file name.

Also you can check the relevant INI setting by running following statement via ISQL command line utility:

SQL> select cfg_item_value (virtuoso_ini_path (), 'Parameters',

ACL's work in the following way:

All paths are converted from relative to absolute paths.
The path beginning with <http_root> is always allowed.
All DB files are always access denied (.db, db segments, .trx, log segments, .ini specified in INI file etc.)
If a path is not allowed or exists as denied then access to the file is rejected.
If a requested path is allowed and not in denied then access is allowed.
ACL's are inherited. If a directory allows access so does its subdirectories.

The following functions are restricted by file Access Control Lists (ACL) in the virtuoso.ini file:

[Note] Note:

the cfg_write function has restrictions against changing file access control lists in ini file