| Name |
Description |
| Historian and Advanced Historian |
Advanced Historian Only |
|
-bg |
Set the RTView application to run as a background process. When this option is
specified, the GmsLauncher process and run scripts exit immediately after the
RTView application is started, rather than continuing to run, thereby reducing
the host system process count. However, note that:
- The RTView application output and error
messages will not appear in the command/shell window from which it was
launched.
- Ctrl-c cannot be used to terminate the
application.
NOTE: This option is only recognized on the
command line and is not read from, or saved to, any RTView options (.ini)
files.
Example:
-bg |
|
| -cachelast |
Store
only the last (most
recent) values in the cache for each unique data attachment. By default, the
Historian stores all records in the cache each time the -cachesize or -cachetime
limit is reached.
This option allows the Historian
to store less data than it receives, which can be useful in a configuration where the Historian receives data from the
Data Server at a higher rate than necessary for historical storage.
Example:
-cachelast |
|
| -cachesize:(records) |
Set the cache size. The Historian
will cache the specified number of records and then commit them all to
the database at one time.
Example:
-cachesize:50
|
|
| -cachetime:(seconds) |
Set the cache time. The Historian
will cache records for the specified number of seconds and then commit
them all to the database at one time.
Example:
-cachetime:60
|
|
| -charlimit |
Specify the
maximum number of characters for a String column in
a database table created by the Historian. The default is 50.
This option allows the Historian
to generate tables with larger String columns, rather than manually configuring
each table.
For example, in the command line:
-charlimit:NNN
and in HISTORY.ini:
charlimit NNN
where NNN specifies the maximum number of characters (for example,
-charlimit:300). The Historian creates a VARCHAR column with the specified
limit (for example VARCHAR(300)) for all String columns. However, be
aware that each database vendor has a different upper limit on the maximum
VARCHAR length. If you specify a charlimit value that is larger than the
database vendor limit, errors might occur when the Historian creates a database
table. Consult your database documentation for details.
To store very long strings, you can specify MAX as the charlimit
value rather than a number. For example, on the command line:
-charlimit:MAX
and in HISTORY.ini:
charlimit MAX
When MAX is specified as the value for the charlimit option, the
type of database column created by the Historian for text columns depends on the
specific database, as follows:
Database: Column Type Declaration for charlimit=MAX
HSQLDB: VARCHAR
SQL Server: VARCHAR(MAX)
Oracle: VARCHAR2(4000)
DB2: CLOB
MySQL: TEXT
Sybase: TEXT
Each of these column types allows for the storage of very long strings. Consult
your database documentation for details. |
|
|
-compactiontimerinterval |
|
Specifies
the time interval, in seconds, for the compaction thread to sleep before
checking for work. The default is 5 seconds. Example:
-compactiontimerinterval:5 |
| -compactionverbose:n |
|
Specifies
whether and how to output to the console. There are three options:
0 - No information is output to the
console.
1 -
Summary information is output to the console.
2 - Debug-level information is
output to the console.
Example:
-compactionverbose:1 |
| -daemon |
Run the Historian as a daemon process.
NOTE: This parameter must be the first command line argument given.
Example:
run_historian
-daemon
|
|
| -dbname:(name) |
Set the name of the history
database.
NOTE: This name must match the Data Source Name specified when you registered
your database with ODBC, as well as the name of the history database configured in
the Display Builder's SQL Application Options tab.
Example:
-dbname:RTVHISTORY
|
|
|
-exit_on_out_of_memory |
Force the
Historian to
terminate when an OutOfMemoryException occurs.
This option is intended for use in a HA
deployment where a backup server is available, otherwise the process may
continue to run in a crippled state and prevent the backup from taking over.
NOTE: The Historian is not automatically
restarted by this option and must be restarted manually.
Example:
-exit_on_out_of_memory |
|
| filename |
Add
a data configuration (.rtv) file to the Historian.
Example:
run_historian
config.rtv
|
|
| -insertcolumnnames |
Include column names in
the database insert statements for user-defined tables. This is useful when the
Historian is adding data to existing tables and the column order is not an exact
match or the insert statement contains a subset of the existing table columns.
NOTE: This option does not apply to the HISTORY and
HISTORY_S tables.
Example:
-insertcolumnnames |
|
| -jmxport:(port
number) |
The port number
to use to expose JMX methods to monitor
and manage the Historian. There is no default port. If not specified,
these JMX methods will not be accessible.
Example:
-jmxport:9996
|
|
|
-log4j |
Turns on Log4j logging for the RTView application. By default, RTView processes
print log messages
to the console. To obtain log files, redirect the RTView application
output and error streams to a log file using Log4j.
After starting
Log4j, the first
time-stamped row in the log file appears as follows:
2012-02-02 14:00:54,693 INFO – [rtview] Log4j is being used with
sl.log4j.properties as the configuration file.
When
Log4j
is not in use, the first time-stamped row in the log
file appears as follows:
2012-02-03 10:40:31.866 [rtview] Logging redirected for System.out and
System.err. Log4j is not in use.
(Note the missing INFO column when
Log4j
is not in use.)
For example:
run_historian –log4j
run_historian –log4j –log4jlevel:INFO –showlogcat
To
run the Historian as a background process
using
the -bg command line argument, use
the
sl-bg.log4j.properties configuration file
(which only outputs to a log file rather than to a console) and the -daemon
argument.
-bg (background) example:
run_historian
-daemon
–bg –log4j
–log4jprops:sl-bg.log4j.properties
NOTE: The logging method from previous versions
of RTView does not use Log4j. This previous method of logging is enabled with
-logfile and –logdir and is still supported. Do not use both the
previous logging method and Log4j or you receive the following error message:
ERROR: log4j configuration ERROR - com.sl.rtview.useLog4j is set to true but
-logfile redirection is in use. Log4j will not be used. |
|
| -showlogcat |
Turns on the
Category column in the log file output. When not in use, the
Category column is not shown in the log file. When not in use, the
Category column is not shown in the log file. For example:
-showlogcat |
|
|
-log4jprops |
Specify the .properties file to
use to format the Log4j log file. By default,
sl.log4j.properties
is used. Use this to provide a different
property file name. The .properties file
is searched for inside a .jar/.war file,
then searched for in the current directory, and lastly searched for in the %RTV_HOME%/lib
directory. The filename can have a path preceding it. For example,
C:\mydir\my.log4j.properties. For example:
-log4jprops:mylogfile.properties |
|
|
-log4jlevel |
Specify the Log4j
Level. INFO is used by default. Valid values are:
FATAL: Indicates a severe error
that likely causes the application to abort.
ERROR: Indicates an event that might
not cause the application to abort.
WARN: Indicates a potentially harmful
event.
DEBUG: Indicates detailed
informational about events for debugging the application.
INFO: Indicates informational
messages about the progress of the application at coarse-grained level.
For example:
-log4jlevel:INFO |
|
| -logdir |
Specify to prefix the log file name that is set in the -logfile option to
the directory name in which the log file is stored. If the -logfile option is not specified, this
option is ignored.
NOTE: This option is only recognized on the
command line and is not read from, or saved to, any RTView options (.ini)
files.
Example:
-logdir:ABCcompany |
|
| -logfile |
Specify the redirection of output and error messages to a file. The RTView
application output and error message streams are redirected to the specified
file. The file is created if it does not exist. If the file does exist, its
previous contents are cleared.
NOTE: This option is only recognized on the command
line and is not read from, or saved to, any RTView options (.ini) files.
Example:
-logfile:Historian.log |
|
| nogui |
Specifies
to run the Historian as a daemon process. NOTE: This parameter must be the first
command line argument given.
Example:
run_historian -nogui |
|
| -noreset |
Do not clear database tables before
storing new data.
Example:
-noreset
|
This option does not apply to the Advanced
Historian. |
| -processName |
Specify to identify applications running as
background processes. This option tags a unique identifier onto RTView
server instances, enabling you to differentiate between multiple instances of
those RTView applications. This option allows you to stop a particular instance
without eliminating the other instances. If no process name is specified, the
RTView application name is used as the process name.
For example,
run_builder -processName:XX
adds the following JVM option to the Java call:
-DPROCESS_NAME=XX
Where XX is the value you specified for the -processName argument.
NOTE: Values with spaces cannot be used for this option on Unix.
Example:
-processName:XX |
|
|
-rebuildtables |
On
startup, delete all existing Historian tables (including HISTORY and HISTORY_S)
and recreate them. Example:
run historian
-rebuildtables
It is
also possible identify specific tables to rebuild (i.e. delete and recreate). NOTE: Table names are case-sensitive
and may not contain spaces. Example:
-rebuildtables:Table1,Table2,Table3
NOTE:
User-defined tables will be rebuilt as data is received for each table. |
Do not use
-rebuildtables in conjunction with the -smoothCompaction option
because older data will be lost when the Historian tables are rebuilt. |
| -retention |
Specify (in minutes) the
length of time records can exist before they are deleted.
Example:
-retention:5 |
In the Advanced Historian,
compactionRules specify how long records can exist before they are
compacted or deleted. Go to Caches>Introduction>Historian Properties. |
| -retentionMax |
Specify (in minutes) the
maximum length of time that may pass before retention processing is performed.
NOTE: If the -retention
time set is shorter than the specified -retentionMax, then the record's
retention span is used.
Example:
-retentionMax:60 |
Specify (in minutes) the maximum length of time that
may pass before retention processing is performed -- this setting only
applies to the compaction rule with the longest retention amount.
For tables that do not have compactionRules set,
this option defaults to basic Historian behavior.
NOTE: If the span of the compaction rule with the
longest retention amount is shorter than the specified -retentionMax, then the
compaction rule span is used.
Example:-
-retentionMax:60 |
| -smoothcompaction |
|
Based on specified
compactionRules, perform compaction on old data that currently exists in
your database from prior executions of the Historian.
Do not use the -rebuildtables option in
conjunction with -smoothCompaction because older data will be lost when
the Historian tables are rebuilt.
Example:
-smoothcompaction
NOTE: This option is not recommended if the
Historian has a heavy load of data to process or the Historian database is being
used by other applications.
|
| -sub:(substring:subvalue) |
Add a substitution string/value pair.
Multiple substitution pairs can be specified on the command line.
NOTE: Substitution strings cannot contain the following:
|
:
|
|
|
.
|
tab
|
space
|
,
|
;
|
=
|
<
|
>
|
'
|
"
|
& |
/ |
\ |
{ |
} |
[ |
] |
( |
) |
If your substitution value contains
single quotes, you must escape them using a /.
Example:
-sub:$data:myData
-sub:$filter:Plant=/'SanFrancisco/'
|
|
| -tablename:(tablename) |
Specify the table name (e.g., MY_TABLE)
to use when archiving data. NOTE: Table names cannot contain spaces. The
name you specify will be used for the numeric table and an _S will
be appended to that name for the string table (e.g., MY_TABLE_S).
Example:
-tablename:MY_TABLE
|
|
| -timestamp:(type) |
Specify the type of timestamp.
There are three options:
| none
|
No TIMESTAMP
column is stored. |
| sql |
A single
TIMESTAMP column is stored using a standard SQL TIMESTAMP data type. |
| str |
Two TIMESTAMP
columns are stored with each record as strings. |
Example:
-timestamp:sql |
|
| -timezone |
Set the default timezone
for interpreting and displaying dates. Include a Java timezone
ID or a custom ID, such as "GMT-8:00". Unrecognized IDs will
be treated as GMT.
If you run the RTView Builder with a valid timezone parameter and then save Application
Options, the timezone information will be persisted.
To prevent the persisted
timezone value from being used, pass "none" as the timezone ID.
Example:
-timezone:US/Eastern
-timezone:none |
|
| -u(milliseconds) |
Set
update rate in milliseconds. Default is 2000.
Example:
-u5000
(updates every 5 seconds) |
|
| -verbose |
Set the Show
Data in Console flag to true so that a line is printed to the console for
each record that is stored in the database.
Example:
-verbose
|
|
| Name |
Description |
|
-actionauditdb:(database) |
Specifies name of a database connection, as defined on the SQL tab, in which to
store alert actions audit information. Example:
-actionauditdb:ALERTBD |
|
-actionaudittable:(table) |
Specifies name of the table in the Alert Action Audit Database in which to store
the alert actions audit information. Example:
-actionaudittable:ACTION_AUDIT_TABLE |
| -alertcleartime:(number of seconds) |
Specifies the rate, in seconds, to remove
cleared alerts.
Example:
-alertcleartime:3 |
| -alertds:alertdef:(filename) |
Adds an alert definition file. Cannot specify
substitutions. To specify substitutions, use the
Application Options dialog.
Example:
-alertds:alertdef:myalerts.rtv |
| -alertds:enabled:(true or false) |
Enables/disables all alerts in the
active alert definition files.
Example:
-alertds:enabled:false |
| -alertds:history:(size of table) |
Sets the number of rows
that are stored in the AlertTable.
Example:
-alertds:history:1000 |
| -alertinitdelay:(number of
seconds) |
Specifies the duration, in seconds, to
wait after startup to begin executing alerts.
Example:
-alertinitdelay:5 |
| -enableactionaudit:(true or false) |
If true and configured, alert actions will be
stored to the specified database table. Example:
-enableactionaudit:true |
| -ignorelutforcount:(true
or false) |
If true, the
AlertTable Count column
increments for an alert when new data is received even if the Last Update
Time has not changed. This can cause invalid Counts for alerts attached to
caches.
If false or not specified, the AlertTable
Count column increments for an alert only if the Last Update Time has
also updated. This is the default behavior.
Example:
-ignorelutforcount:true |
|
-lutupdatesnewdata:(true or false) |
Enables\disables updates to the
AlertTable
when New Data Only
is selected and to the alert persistence
database when the only columns that contain changes for
that row are Last Update Time and Count. By default, the
Last Update Time and Count columns are not tracked by the
Row
Update Time column. To track the updates of the two columns in the Row Update Time
column, use the -lutupdatesnewdata command line option.
Example:
-lutupdatesnewdata:true |
| -multipleindexdelim:(string) |
For alerts with multiple index columns, create a unique alert index by concatenating
all of the index column values. Value can be any string, except the following:
- comma (,)
- semi-colon (;), or
- empty
string.
Default is
tilde (~). Example:
-multipleindexdelim:~ |
| -persistInitDelayTime:(number of
seconds) |
Specify the amount of time, in seconds, to
delay a backup Data Server from reading the alert persistence database during a
failover. The default is 5 seconds. Increase the amount of time if the
persistence database is slow or if you expect a large number of alerts to change
on each update period. Otherwise, there might not be enough time for the failing
Data Server to write all the alerts to the database before the backup server
reads them.
NOTE: Even with high availability configurations, there are cases in which some
alerts might not be persisted. For example:
- The persistence database fails. In this
case, alerts cannot be written to, or read from, the database. If a failover
occurs while the database is down, the backup server will not be able to
read persisted alerts from the database. This will also happen if
persistence is configured to use a Persistence Data Server to access the
database, and the Persistence Data Server is down during failover.
- The Alert Server is terminated in a
non-orderly shutdown. Alerts are written out once per update period and once
during orderly termination. If there is a non-orderly shutdown, some alerts
might not be written to the database.
In cases where alerts are not persisted, the
new primary Data Server generates new alerts if the data is still in an
alert state. The new primary Data Server might also re-use ID's that were
used by the failed Data Server. Example:
-persistInitDelayTime:10 |
