13.01.2013 Views

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

OpenEdge Data Management: DataServer for Microsoft SQL Server

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Additional Features to Enhance <strong>Data</strong><strong>Server</strong> Per<strong>for</strong>mance<br />

4–6<br />

Fast Forward-Only cursors<br />

In the event that a firehose cursor cannot be used, the <strong>Data</strong><strong>Server</strong> attempts to use a Fast<br />

Forward-Only (FFO) cursor with Auto-Fetch and Auto-Close attributes. FFO cursors are the<br />

server-side equivalent of firehose cursors. FFO cursors have special optimization characteristics<br />

that distinguish them from other server-side cursors. They require a minimum of server-side<br />

resources and are capable of minimizing round trips to the server. FFO cursors are an extension<br />

to the ODBC specification and are unique to ODBC drivers that con<strong>for</strong>m to <strong>Microsoft</strong> <strong>SQL</strong><br />

<strong>Server</strong> driver requirements. The Auto-Fetch attribute directs the server to return the initial block<br />

of results in the same network message that provided the <strong>SQL</strong> request to be executed by the<br />

server. The Auto-close attribute directs the server to automatically close the cursor on the same<br />

round trip in which the last query result is received by the client.<br />

Note: Result sets that include text or image columns cause an implicit conversion from an<br />

FFO to a dynamic cursor type. These are columns that translate through ODBC to <strong>SQL</strong><br />

LONGVARCHAR and LONGVARBINARY data types.<br />

Monitoring cursor and connection use<br />

Monitor the use of your managed connections to tune the number of connections you allocate.<br />

If you regularly exceed your allocation, consider increasing the number of managed<br />

connections. If you never use your total allocation, consider decreasing the number of managed<br />

connections.<br />

You can monitor connections either through using <strong>OpenEdge</strong> logging or by enabling logging<br />

using the “-Dsrv qt_debug,cursor” switch.<br />

Note: The <strong>OpenEdge</strong> logging infrastructure offers more extensive reporting capabilities than<br />

qt_debug. For details on enhanced logging, see<br />

Monitoring connections with qt_debug<br />

The <strong>Data</strong><strong>Server</strong> log contains messages indicating the status of connections. At startup, the<br />

number of managed connections initialized is written to the log file. If connections are rejected,<br />

this is also logged. If a connection from the ODBC connection pool cannot be reused, the ODBC<br />

driver issues the message DEAD Connection which is written to the log file.<br />

At the end of a session, the <strong>Data</strong><strong>Server</strong> writes summary in<strong>for</strong>mation about cursor use. The<br />

summary contains the following in<strong>for</strong>mation:<br />

• Needed connections — The number of connections actually used during a session<br />

• Peak connections — The maximum number of connections used simultaneously during<br />

a session<br />

When debug logging is enabled with the “-Dsrv qt_debug,cursor” switch, a summary of<br />

connection activity is written to the log file. This summary contains:<br />

• Number of connections (defaults to 5)<br />

• Number of peak connections (defaults to 5)<br />

• Highest connection value

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!