Discover with BMC Discovery
download

This product can be discovered by any edition of BMC Discovery. Download our free Community Edition to try it out, or [see what else it can discover] !

What is this?
This is a product information page, containing details of the information that BMC Discovery gathers about a product and how it is obtained.
Product Name
Adaptive Server Enterprise
Publisher Page
Sybase
Category
Relational Database Management Systems
Release
TKU 2016-Sep-1
Change History
Sybase Adaptive Server Enterprise - Change History
Reports & Attributes
Sybase Adaptive Server Enterprise - Reports & Attributes
Publisher Link
Sybase

Product Description

 

Extended Discovery pattern which allows to model Database Detail Nodes being managed by the Sybase Database Server  is available for this product.

 

Sybase Adaptive Server Enterprise (ASE) is an enterprise-class relational database management system product. ASE is predominantly used on the Unix platform (Solaris, HP-UX, AIX, Linux) but is also available on Microsoft Windows.

ASE was originally called Sybase SQL Server (until version 11.5), but was then renamed to differentiate it from Microsoft SQL Server. Major Sybase ASE Components are the Database Server (Data Server), the Monitor Server, and the Backup Server.

Known Versions

  • 10.0
  • 11.0
  • 11.5
  • 11.9
  • 12.0
  • 12.5
  • 15.0
  • 15.1
  • 15.5
  • 15.7
  • 16.0

Software Pattern Summary

Product ComponentOS TypeVersioningPattern Depth
Database ServerUnixCommand (Active), Path, SQL queryInstance-based or Footprint (data dependent)
WindowsCommand (Active), Path, RegistryInstance-based
Backup ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
WindowsCommand (Active), Path, RegistryInstance-based
Monitor ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
WindowsCommand (Active), Path, RegistryInstance-based
Monitor Historical ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
WindowsPathInstance-based
XP ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
WindowsPathInstance-based
LinkMonitorServerToDataserverN/A
LinkDataServerToMonitorServer
LinkXPServerToDataserver
LinkDataServerToXPServer

Platforms Supported by the Pattern

The patterns have been created in a manner that allows each of them to support Windows, Linux and Unix platforms from the same module.

Identification

Sybase ASE is composed of 4 major components (with sub-components) which are:

  • Database Server (Data Server) - server hosting one or more databases.
  • Monitor Server - provides a way to monitor Adaptive Server performance in real time or historical data-gathering mode. Delivers feedback for tuning at several levels - Adaptive Server configuration, Database design, SQL statements in applications and stored procedures
  • Monitor Historical Server - provides a way to monitor Adaptive Server performance in historical data-gathering mode.
  • Backup Server - dedicated to backing up and restoring Adaptive Server files.
    An optional component may also be running:
  • XP Server - allows implementation of Extended Stored Procedures (ESPs). These procedures contain code to carry out functions and tasks external to the server in response to events occurring within the server.

Software Instance Triggers

ComponentTrigger NodeAttributeConditionArgument
DatabaseServerDiscoveredProcesscmdmatchesregex'(?i)\bsqlsrvr\.exe$'
or
cmdmatchesregex'\bdataserver$'
argsmatches

regex '(?:^|\s)-\w\s*(?:\S+)'

 
 
BackupServercmdmatchesregex'\bbackupserver$'
or
regex'(?i)\bbcksrvr\.exe$'
MonitorServercmdmatchesregex'\bmonserver$'
or
regex'(?i)\bmonsrvr\.exe$'
MonitorHistoricalServercmdmatchesregex'\bhistserver$'
or
regex'(?i)\bhistsrvr\.exe$'
XPServercmdmatchesregex'\bxpserver$'
or
regex'(?i)\bxpserver\.exe$'
LinkMonitorServerToDataserverSoftwareInstancetype="Sybase ASE Monitor Server"
LinkDataServerToMonitorServer"Sybase ASE Database Server"
LinkXPServerToDataserver"Sybase ASE XP Server"
LinkDataServerToXPServer"Sybase ASE Database Server"

Simple Identification Mappings

The following components/processes are identified using the combination of pattern definitions and simple identity mappings which map other known (but deemed less important in terms of application modeling) processes.

NameCommand
Sybase Interactive Database clientisql, isql.exe, isqlw.exe, dbisql.exe, dbisqlc.exe or dbisqlg.exe
Sybase Interactive Database client - SQL shellsqsh
Sybase OpenClient/OpenServer Configurationocscfg.exe
Sybase ASE Monitor Servermonserver or monsrvr.exe
Sybase ASE Monitor Historical Serverhistserver or histsrvr.exe
Sybase ASE Backup Serverbackupserver or bcksrvr.exe
Sybase ASE Backup Server sybmultbuf processsybmultbuf
Sybase ASE Database Serversqlsrvr.exe or dataserver
Sybase ASE Database Server enginedataserver -ONLINE
Sybase ASE Job Scheduler Agentjsagent or jsagent.exe
Sybase ASE Sybase Central - Java Editionscjview or scjview.exe
Sybase ASE XP Serverxpserver or xpserver.exe
Sybase ASE Server Configurationsyconfig.exe
Sybase ASE Unified Agent Serviceuaservice.exe

Versioning

Version information for the product is currently collected using one of three possible methods.

The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:

SQL Query

Database Server

Pattern executes sql query := "select @@version";

From the target output retrieves full version using regex :

  • (?i)Adaptive\sServer\sEnterprise/(\d+(?:\.\d+)*)

Active Versioning

Unix/Linux

The "Active Version Command" method involves either an execution of a single pipeline combining a static command, a dynamic argument from the triggered process command line followed by additional static options/commands, or a more complex command pipeline construction and execution in steps coordinated within the pattern itself.

For Sybase ASE components, the single pipeline approach is used. It uses a combination of a static version command, a dynamic argument from the matched command line followed by additional static options (if applicable).

The command is run once the process has been matched and only if the regular expression used matches the supplied command.

This approach is taken for:

Database Server

Two different variations of the single pipeline approach are used:
1. 'strings' command is executed against a logfile specified by the '-e' argument of the Database Server process command line. The output is parsed for the line containing: 'kernel Adaptive Server Enterprise/' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of strings %logfile_path% | grep "Adaptive Server Enterprise/"' is parsed for:

kernel\s+Adaptive Server Enterprise/(\d+\.[d.]*\d)/

If more than one version is returned, the last occurence in the file is taken as the version.

2. If the version is not obtained using the first approach, a secondary active command version variation is used. In this variation, the actual binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Adaptive Server Enterprise /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of '/<absolute_path_to_binary/dataserver -v' is parsed for:

Adaptive Server Enterprise/(\d+\.[d.]*\d)/

If more than one version is returned, the last occurence in the file is taken as the version.

NOTE: The first variation of the active version command requires the command-line arguments of 'dataserver' process to contain the path to the logfile (specified by '-e' argument) and that the logfile can be accessed.

The second variation requires that Foundation obtains the absolute path to the 'dataserver' binary and that the user credentials of the Foundation user provide the level of access to allow execution of the binary.

Backup Server

Two different variations of the single pipeline approach are used:
1. 'strings' command is executed against a logfile specified by the '-e' argument of the Backup Server process command line. The output is parsed for the line containing: 'Backup Server/' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of 'strings <logfile> | grep "Backup Server/"' is parsed for:
Backup Server/(\d+\.[d.]*\d)/

If more than one version is returned, the last occurence in the file is taken as the version.

2. If the version is not obtained using the first approach, a secondary active command version variation is used. In this variation, the actual binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Backup Server /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.
Process: output of '/<absolute_path_to_binary/backupserver -v' is parsed for:
Backup Server/(\d+\.[d.]*\d)/

NOTE: The first variation of the active version command requires the command-line arguments of 'backupserver' process to contain the path to the logfile (specified by '-e' argument) and that the logfile can be accessed.
The second variation requires that Foundation obtains the absolute path to the 'backupserver' binary and that the user credentials of the Foundation user provide the level of access to allow execution of the binary.

Monitor Server

The Monitor Server binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Monitor Server /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of '/<absolute_path_to_binary/monserver -v' is parsed for:
Monitor Server/(\d+\.[d.]*\d)/

Monitor Historical Server

The Monitor Server binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Monitor Historical Server /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of '/<absolute_path_to_binary/histserver -v' is parsed for:
Monitor Historical Server/(\d+\.[d.]*\d)/

Windows

The "Active Version Command" function calls a static version command.

The command is run once the process has been matched and only if the regular expression used matches the supplied command.

This approach is taken for:

Database Server

The version command results in the sqlsrvr.exe command being run with the '-v' argument appended. The output is parsed for the phrase: 'Enterprise/<version>/' and the <version> numeric output is captured as the version.

Command:

Version Command Regex: (?i)(^\w:.+\\sqlsrvr.exe)\s

Options: -v

Version Regex: Enterprise/(?P<version>(\d+(\.\d+)*))/

This active version command works on the Windows platform because Sybase prevents you from ing Sybase ASE into a directory whose name contains one or more space characters.

Path Versioning

The Path Regex functionality allows a regular expression to be applied against the process command line to derive a version number from the command path or arguments.

Currently, versioning of Sybase Adaptive Server Enterprise is performed on Unix/Linux and Windows by reading information within the command-line path using one of the following regular expressions:

Unix/Linux

This approach is taken for:

Database Server

If "active version command" approach does not yield a version (e.g. access to the logfile is not obtained, or path to the logfile cannot be extracted from the command line), path regex parsing approach is taken.

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)((?:\.\d)?)((?:\.\d)?)

Versioning is achieved in this case to depth x.x, x.x.x or x.x.x.x depending on the data available on the process command-line.

Examples of paths that would be matched and versions extracted are:

  • /opt/sybase/INFR/<Server_name>/ASE-12_5/bin/dataserver - 12.5
  • /opt/sybase/12.5.0.3/ASE-12_5/bin/dataserver - 12.5.0.3
  • /opt/sybase/12.0.0.8/ASE-12_0/bin/dataserver - 12.0.0.8
  • /opt/Sybase/12.5.3/ASE-12_5/bin/dataserver - 12.5.3

Backup Server

If "active version command" approach does not yield a version (e.g. access to the logfile is not obtained, or path to the logfile cannot be extracted from the command line), path regex parsing approach is taken.

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

  • /opt/sybase/TEST/<Server_name>/ASE-12_5/bin/backupserver - 12.5
  • /opt/sybase/12.5.3/ASE-12_5/bin/backupserver - 12.5
  • /opt/sybase/12.0.0.8/ASE-12_0/bin/backupserver - 12.0

Monitor Server

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

  • /home/pharaoh/u1111/sybase_15.0/ASE-15_0/bin/monserver - 15.0
  • /export/apps/sybase/ASE-12_5/bin/monserver - 12.5
  • /opt/sybase/ASE-12_5/bin/monserver - 12.5
  • /opt/sybase/DREL/<Server_name>/ASE-12_5/bin/monserver - 12.5

XP Server

Path Regex method is currently the only method used for obtaining the product version for Sybase ASE XP Server.

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

An example of a path that would be matched and version extracted is:

  • /opt/sybase/IMAG/<Server_name>/ASE-12_5/bin/xpserver - 12.5
  • /opt/sybase/DMR/<Server_name>/ASE-12_5/bin/xpserver - 12.5
  • /export45/apps/sybase/ASE-12_0/bin/<Server_name>/export45/apps/sybase -p8 -s77824 -x - 12.0

Monitor Historical Server

The regular expression used is as follows:

(?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

  • /opt/sybase/ASE-12_5/bin/histserver - 12.5
  • /opt/sybase/DREL/<Server_name>/ASE-12_5/bin/histserver - 12.5

Windows

This approach is taken for:

Database Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Backup Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

  • C:\sybase\ASE-12_5\bin\bcksrvr.exe - 12.5
  • D:\sybase\ASE-15_0\bin\bcksrvr.exe - 15.0

Monitor Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

  • C:\sybase\ASE-12_5\bin\monsrvr.exe - 12.5

Monitor Historical Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

XP Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Example of path that would be matched and versions extracted is:

  • c:\sybase\ase-15_0\bin\xpserver.exe -C -SSTACKXP_XP -IC:\sybase\ini -p8 -s65536 -e1 -lLocalSystem -aSTACKXP - 15.0

Registry Versioning

Windows only

Using registry queries on hosts running Microsoft Windows can at times return the version of the product a process (or processes) belongs to.

This approach is used when it is likely to provide versioning to greater depth than other approaches, or when other approaches (e.g. path regex) are suspected not to provide enough coverage due to the software deployment patterns used.

There are two limitations to the use of Registry Queries and the data returned:

i) If version is obtained using another approach, version will not be obtained using registry query approach even if that data is to lesser depth than the version that would be obtained using registry queries

ii) We cannot always link the process running to a Registry entry. This limitation is similar to the limitations of the versioning using installed packages.

This approach is taken for:

Database Server

The key used to determine the version is:

HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\SQLServer\CurrentVersion

Versioning is achieved in this case to depth x.x.x or x.x.x.x

Backup Server

The approach will execute if versioning using Regex Path hasn't succeeded and also requires the command-line arguments for Backup Server containing the server name (-S argument followed by a server name).

The key used to determine the version is:

HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\Server\<server name>\Version

If executed, versioning that can be achieved is to depth x.x.x or x.x.x.x

Monitor Server

The approach will execute if versioning using Regex Path hasn't succeeded and also requires the command-line arguments for Monitor Server containing the server name (-M argument followed by a server name).

The key used to determine the version is:

HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\Server\<server name>\Version

If executed, versioning that can be achieved is to depth x.x.x or x.x.x.x

Alternative Versioning Approach

We are currently aware of one other potential method to obtain version information for the Database Server and Backup Server on Unix/Linux using Active Version command approach. This method is an extension of the current approach.

Detailed Logfile Parsing

The current version command approach that parses the Database Server or Backup Server logfiles assumes that the logfile has been generated by the version of the server that is currently running. It is possible however, that the server has been upgraded to a later version without re-setting the logs. In this case, the version returned may no longer be correct.

An approach to rectify this could be to parse the whole file for lines containing:

'kernel Adaptive Server Enterprise/' or 'Backup Server/' respectively, and use output obtained from the last line.

This would ensure accuracy, but could have serious performance implications every time a large logfile is encountered. Due to the high probability of performance impact this approach is unlikely to be implemented.

Future Considerations

Application Model Produced by Software Pattern

Product Architecture

An ASE installation typically comprises one "dataserver" which hosts several databases. Some of these are "system" databases which store only meta-data used to keep the system operational. The others are "user" databases which store application data in the form of tables and stored procedures.

Backup Server can either be resident on the same host as the Database Server, or be located in a remote location.

Monitor Server, Monitor Historical Server and XP Server all need to be located on the same host as the Database Server.

Software Pattern Model

An ASE installation typically comprises one "dataserver" which hosts several databases. Some of these are "system" databases which store only meta-data used to keep the system operational. The others are "user" databases which store application data in the form of tables and stored procedures.

Database Server

The Database Server pattern is triggered by the Database Server process (dataserver or sqlsrvr.exe). The name of the database server running is extracted from the command-line arguments using the following regular expression, '(?:^|\s)-\w\s*(?:\S+)' . This name is used to create a unique SI.

On Unix hosts, the trigger process is combined with a set of its parent processes as well as any child processes to the trigger process.

SI Depth

The server name and version contribute to a unique key for the instance-based SI that is generated. Where this name is not available, a grouped SI is created which groups database servers based on their version.

Relationship Creation

Associate inference relationship is created between the triggered prime process and children processes launched by this process.

Backup Server

The Backup Server pattern is triggered by the Database Server process (backupserver or bcksrvr.exe). The name of the Backup server running is extracted from the command-line arguments using the following regular expression, '-S(\S+)' on Unix/Linux and '(?i)-S(\S+)' on Windows. This name is used to create a unique SI.

On Unix hosts, the trigger process is combined with a set of its parent processes as well as any child processes to the trigger process.

SI Depth

The server name and version contribute to a unique key for the instance-based SI that is generated. Where this name is not available, a grouped SI is created which groups Backup servers based on their version.

Relationship Creation

Associate inference relationship is created between the triggered prime process and children processes launched by this process.

Monitor Server

The Monitor Server pattern is triggered by the Monitor Server process (monserver or monsrvr.exe). The name of the Monitor server running is extracted from the command-line arguments using the following regular expression, '-M(\S+)' on Unix/Linux platform and '(?i)-M(\S+)' on Windows. This name is used to create a unique SI.

In addition to this, where available on the command-line, the name of the Database Server being monitored is extracted using the following regular expression ('-S(\S+)') and stored as 'db_server_monitored' attribute on the SI node generated. This attribute is later used to model communication between the Database Server and the Monitor Server.

On Unix hosts, the trigger process is combined with a set of its parent processes as well as any child processes to the trigger process.

SI Depth

The server name and version contribute to a unique key for the instance-based SI that is generated. Where this name is not available, a grouped SI is created which groups Monitor servers based on their version.

Monitor Historical Server

The Monitor Historical Server pattern is triggered by the Monitor Historical Server process (histserver). The name of the Monitor Historical server running is extracted from the command-line arguments using the following regular expression, '-S(\S+)' on Unix/Linux and '(?i)-S(\S+)' on Windows.

SI Depth

The server name and version contribute to a unique key for the instance-based SI that is generated. Where this name is not available, a grouped SI is created which groups Monitor Historical servers based on their version.

XP Server

The XP Server pattern is triggered by the XP Server process (xpserver). The name of the XP server running is extracted from the command-line arguments using the following regular expression '-S(\S+)' on Unix/Linux and '(?i)-S(\S+)' on Windows.

In addition to this, where available on the command-line, the name of the Database Server that launched the XP server is extracted using the following regular expression '-S(\S+)_XP' and stored as 'db_server_related' attribute on the SI node generated. This attribute is later used to model communication between the Database Server and the XP Server.

SI Depth

The server name and version contribute to a unique key for the instance-based SI that is generated. Where this name is not available, a grouped SI is created which groups XP servers based on their version.

Communication between Database Server and Monitor Server

Two patterns have been developed to model the communication between the Database Server and Monitor Server. This communication is via shared memory hence isn't detectable via monitoring of open ports, but the Monitor Server command-line usually provides the information about the monitored Database Server via the '-S' attribute. This information is captured in the 'db_server_monitored' attribute of the Monitor Server SI node.

As patterns can trigger in any order, and this relationship can only be created once both Database Server and Monitor Server SIs exist, two patterns are required to ensure that this relationship is created. One pattern triggers when a Database Server SI has been generated, while the other when the Monitor Server SI has been generated.

Only one of these patterns will be successful at any one time.

In either case, once triggered, the pattern searches for either the Database Servers or the Monitor Servers (depending on the pattern) where the 'db_server_monitored' attribute of the Monitor Server SI node matches the name of the Database Server on the same host.

For each match that occurs, a communication relationship of type 'Client-Server' is created.

Communication between Database Server and XP Server

Two patterns have been developed to model the communication between the Database Server and XP Server. This communication is established when the Database Server needs to launch the XP server in order for external stored procedures to be executed. The XP Server command-line usually provides the information about the Database Server via the '-S' attribute. By default, the name of the XP server is the same as that of the Database Server with '_XP' string appended. This information is captured in the 'db_server_related' attribute of the XP Server SI node.

As patterns can trigger in any order, and this relationship can only be modeled once both Database Server and XP Server SIs exist, two patterns are required to ensure that this relationship is modeled. One pattern triggers when a Database Server SI has been generated, while the other when the XP Server SI has been generated.

Only one of these patterns will be successful at any one time.

In either case, once triggered, the pattern searches for either the Database Servers or the XP Servers (depending on the pattern) where the 'db_server_related' attribute of the XP Server SI node matches the name of the Database Server on the same host.

For each match that occurs, a communication relationship of type 'Peer to Peer' is created.

Installation Root

The product's installation root is extracted by parsing the trigger process' command line or its arguments against the following regular expressions:

UNIX

  • (?i)(?:^|\s)-M(/\S+)

  • (?:^|\s)-(?:e|l)(\S+/(?:sybase|ASE(?:-\d+_\d)?))(?:\s|/)

  • ^(/\S+/ASE(?:\-\d+_\d)?)

Windows

  • ^(\S+\\ASE-\d+_\d+)

Base Path

The product's base path is extracted by parsing the trigger process' command line or its arguments against the following regular expressions:

UNIX

  • (?:^|\s)-(?:e|l)(\S+?)/ASE(?:\-\d+_\d)?

  • -I(\S+)

  • ^(/\S+)/ASE(?:\-\d+_\d)?

Windows

  • ^(\S+)\\ASE-\d+_\d

Log file path

Log file path is extracted from the arguments line with help of the following regexes:

for Unix -

(?:^|\s)-e(\S+)

for Windows -

  • (?:^|\s)-e[\'\"]?([^\'\"]+)
  • (?:^|\s)-e([\S]+)

If log path was not extracted and instance is known the pattern sets '<install_root>/install/<instance>.log' as a log file.

If log file wasn't found pattern searches for <installation_path>\install\server.log file

Bind Address

UNIX platform only

The DatabaseServer pattern attempts to get the bind address for a given Sybase database server. Such information is retrieved from the 'interfaces' file which is relative to the product's installation path using the following regular expression:

  • regex '\((\d+(?:\.\d+)+)\)'

The bind address may also be set to one of the host's alternative IP addresses as mentioned in the comment header for a particular Sybase database server section within the contents of the interfaces file itself.

Port Information

The DatabaseServer, BackupServer and MonitorServer patterns attempt to get port information for the product. On UNIX, such information is retrieved from the 'interfaces' file which is relative to the product's installation path. On Windows, such information is retrieved from the 'sql.ini' file in the 'ini' directory relative to the product's installation path.

Background

The sql.ini or interfaces file is a programmatically generated block for each server. Although several formats exist, each block normally consists of one of the following formats:

TEAPOT
 query tcp ether london-north 5008
 master tcp ether london-north 5008

or

## 
TEAPOT - dev backup 
##
on london-north (192.168.100.101) port 5013

The lines in the former method together constitute the "main server section". The lines in the latter method together constitute the "server section header"

Parsing the Interfaces file

The pattern searches in two overlapping sections of the interfaces file for the port information: the main server section and server section header

The server section header

  • Starts with regular expression (?i)^\#\#\s+[\w\-]+\s+\-\-

  • Ends with regular expression ^\s*$

The main server section

  • Starts with regular expression (?i)^\[?%srv_name%\]?(?:\s+\d+\s+\d+)?$

  • Ends with regular expression ^(?:\S+|\s*)$

On Windows the port information is obtained by parsing the main server section with the following regular expression:

  • (?i)\bmaster=[^,]+,%hostname%,(\d+)

On UNIX, port information is obtained by parsing the interfaces file with one of the following regular expressions (tried in this order):

  • Parse the main server section with: (?i)\bmaster tcp ether (?:%hostname%|%host_local_fqdn%)\s(\d+)

  • Parse the main server section with: \bmaster tcp ether %host_ip_addr%\s(\d+)

  • Parse the server section header with: (?i)^\#\#\s+on\s%hostname%\s\(\d+(?:\.\d+)+\)\sport\s(\d+)

  • Parse the main server section with: \bmaster tcp ether [\w\-\.]+\s(\d+)

Listing Sybase Database Installed Options and Obtaining Edition Information

A separate pattern is used to identify and model a selection of Installed Options in the Sybase ASE Database. Additionally, this pattern also attempts to determine the edition of the Sybase ASE installation. For more information on this approach, please refer to the relevant page.

Obtaining detailed Sybase ASE Database and table information

A separate pattern has been created to query the Sybase ASE Database Server in order to obtain database list and (optionally) database table details. For more information about this pattern, please refer to the relevant page

Subject Matter Expertise

The set of fingerprints for Database Server and Backup Server running on Unix/Linux hosts, including approaches used to version the product have been developed with input from external Subject Matter Experts.

Subject Matter Expert input will be welcome on any other potential approaches not discussed to improving product versioning coverage and depth of Sybase ASE components.

Sybase ASE Database Server process identification on Unix/Linux has been updated based on feedback from external Subject Matter Experts. Identification changed from 'dataserver .-e' to 'dataserver .-s\S' as '-s' command-line argument is more likely to be present on the process command line, whereas '-e' is more likely to be an optional argument and not always be present.

Testing

Unix/Linux

Testing to ensure the processes related to Sybase ASE components have been correctly identified has been performed using Foundation record data from hosts running Solaris, AIX and Linux operating systems.

Record data also contained enough information to extract the version information for all three major components (Database Server, Backup Server, Monitor Server) using the Regex Path versioning approach.

In addition to this, active version command approach was developed and initially evaluated both on in-house Sybase ASE installations and on customer sites. The approach taken was shown to work well provided the environment conditions this approach requires were met.

Windows

Testing to ensure the processes related to Sybase ASE components have been correctly identified has been performed using in-house Sybase ASE installations.

Path regex and Registry versioning approaches were also tested against in-house Sybase ASE installations and were deemed to work well unless constrained by the data returned from the hosts (e.g. Foundation discovery typically cannot obtain process command-line on hosts running Windows NT or Windows 2000 Server. This limitation no longer exists on hosts running Windows XP or Windows 2003 server).

Information Sources

Open Issues

N/A


Created by: Rebecca Shalfield 19 Oct 2007
Updated by: Alex Kashkevich 18 Apr 2014
Reviewed by: Chris Blake 8 August 2013

Was this page helpful? Yes No Submitting... Thank you