Shared log files are shared by all sessions that connect as the same user. If you have multiple users connecting with the same user account, all those sessions will be inserting records into and deleting records from the same log file data table.

When you want to use shared log files

Use shared log files if you have a large number of concurrent sessions, each session connects using an individual DBMS user account (which is the recommended way for making connections to the geodatabase), and you are not using SQL Server to store your geodatabase.

When you might not want to use shared log files

You may not want to use shared log files if you have numerous connections made with the same login such as if you use an ArcIMS service that generates multiple connections with the same login. This can lead to contention and wait times for the SDE_LOGFILE_DATA table. In those cases, you might want to use session-based log files.

If you store your geodatabase in SQL Server, you would be better off using session-based log files created in tempdb, the default setting for ArcSDE for SQL Server.

Tables created for shared log files

The log file tables used for this option are SDE_LOGFILES and SDE_LOGFILE_DATA. They are created in the schema of the connecting user the first time the user makes a selection that exceeds the selection threshold. For ArcGIS Desktop, this threshold is 100 records.

SDE_LOGFILES stores information about each selection set (log file) that is created. The logfile_name and logfile_id columns in this table uniquely identify the name of the log file, and the logfile_id column links the log file record to the SDE_LOGFILE_DATA table. The SDE_LOGFILE_DATA table contains the logfile_data_id and the feature identifier for the selected records.

All records are deleted as soon as the selection set is cleared to prevent the SDE_LOGFILE_DATA table from growing too large. The SDE_LOGFILES table is truncated when the user's session ends. Both SDE_LOGFILE_DATA and SDE_LOGFILES remain in the user's schema.

Settings to use shared log files

In the SERVER_CONFIG table (sde_server_config in PostgreSQL and SQL Server), the following settings are needed to create shared log file tables:

MAXSTANDALONELOGS = 0

ALLOWSESSIONLOGFILE = FALSE

LOGFILEPOOLSIZE = 0

Settings to control storage of shared log file tables and indexes

There are several parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE table that control how or where log file tables are stored in the database. You do not have to set these to use shared log files, but you can set them if you want to alter how the SDE_LOGFILES and SDE_LOGFILE_DATA tables and indexes are stored in the database.

Which parameters are present and what they control depend on the DBMS being used.

For DB2, Informix, and Oracle, the following parameters control storage for shared log file tables and indexes:

LD_INDEX_DATA_ID

LD_INDEX_ROW_ID

LD_STORAGE

LF_INDEXES

LF_STORAGE

See DB2 DBTUNE configuration parameters, Informix DBTUNE configuration parameters, or Oracle DBTUNE configuration parameters for explanations of these parameters.

For PostgreSQL, the following parameters are used:

LD_INDEX_ALL

LD_STORAGE

LF_INDEX_ID

LF_INDEX_NAME

LF_STORAGE

See PostgreSQL DBTUNE configuration parameters for explanations of these parameters.

For SQL Server, these parameters are used:

LD_INDEX_ALL

LD_STORAGE

LF_CLUSTER_ID

LF_CLUSTER_NAME

LF_INDEX_ID

LF_INDEX_NAME

LF_STORAGE

See SQL Server DBTUNE configuration parameters for explanations of these parameters.

Required user permissions to use shared log files

Since the log file tables are owned by the user, users must be granted privileges that allow them to create the required data objects such as tables. This is required even if the user has read-only access to ArcSDE or ArcSDE is set to be read-only. If these privileges are not granted, users will receive an error message the first time they create a selection set larger than the threshold size for that particular client application. However, once the SDE_LOGFILES and SDE_LOGFILE_DATA tables are created for a user, the ArcSDE administrator can revoke the privileges.

For example:

Ian is a city planner who would only select data from the geodatabase to perform analyses related to his work. Therefore, he would be considered a read-only user. However, for Ian to create the SDE_LOGFILES and SDE_LOGFILE_DATA tables in the city's ArcSDE geodatabase for SQL Server, he needs to have CREATE TABLE privileges.

Rather than grant Ian CREATE TABLE privileges indefinitely, the ArcSDE administrator decides to log in to the geodatabase as Ian, make a selection that exceeds the selection threshold, then revoke Ian's CREATE TABLE privilege.

The following are the required permissions in each DBMS to use shared log file tables:

DB2	Informix	Oracle	PostgreSQL*	SQL Server
CONNECT CREATETAB IMPLICIT_SCHEMA	RESOURCE	CREATE SESSION CREATE TABLE CREATE TRIGGER CREATE SEQUENCE CREATE PROCEDURE	CONNECT USAGE and CREATE on the user's own schema	CONNECT CREATE TABLE

Most DBMSs grant CONNECT (CREATE SESSION in Oracle) privileges to all users by default; therefore, you only need to explicitly grant this permission if you have revoked it from PUBLIC.

*For most PostgreSQL users, you will create a corresponding schema and grant the user AUTHORIZATION on the schema. However, for users to be truly read-only, you cannot grant AUTHORIZATION to them on their schemas. Therefore, you will need to temporarily grant each read-only user USAGE and CREATE permissions on the schema, connect as each user, and perform a selection that will create the log file tables in the user's schema. Then you can revoke the read-only user's CREATE permission from the schema. The USAGE privilege must remain so the user can utilize the log file tables in the future.

Session-based log file data tables are dedicated to a single session and may contain multiple selection sets (log files). Each session that logs in will require a set of tables for selections.

When you want to use session-based log files

You definitely want to use this if your geodatabase is stored in SQL Server. In SQL Server, it is possible to create session-based log files in the tempdb database, which means there are no tables for you to manage in the geodatabase, there is minimal transaction logging, and you don't have to give users CREATE TABLE permissions in the database. Since this is the default setting for geodatabases in SQL Server, you don't need to change the settings to use this log file option.

For the other supported DBMSs, you might use session-based log files if you have numerous concurrent connections being made to the geodatabase with the same login.

When you might not want to use session-based log files

If you have read-only users who connect to the database, you cannot use session-based log files. The only exception to this is in SQL Server databases in which the session-based log file table is created in tempdb.

As mentioned in the following section, the session table is dropped from the user's schema when the session ends. That means it has to be re-created when needed; therefore, users need to have permissions to create tables to be able to use session-based log file tables.

When using the default ArcSDE for SQL Server setting, users do not require CREATE TABLE permission in the database for the session table to be created in tempdb.

Tables created for session-based log files

In Oracle, DB2, Informix, and PostgreSQL databases, three tables are created: SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION<SDE_ID>. SDE_LOGFILE_DATA is not actually used in this case, but it is created automatically. The SDE_LOGFILES table stores information about the selection set plus a session tag <SDE_ID> that is appended to the name of the SDE_SESSION table. The SDE_SESSION table stores the feature identifier for the selected set and the log file ID.

The SDE_LOGFILES and SDE_LOGFILE_DATA tables remain in the geodatabase. The SDE_LOGFILES table is truncated when the connecting application disconnects. The SDE_SESSION<SDE_ID> table is truncated when the connecting application deletes the log files, and the table is dropped when the session disconnects.

In SQL Server, one table is created in tempdb in the format ##SDE_session<sde_id>. This table is truncated when the connecting application deletes its log files, and the table is dropped when the session disconnects. Be aware that you cannot see temporary objects in Enterprise Manager or the Object Explorer in Management Studio.

Settings to use session-based log files (nonpooled)

In the SERVER_CONFIG table (sde_server_config in PostgreSQL and SQL Server), the following settings are needed to create session-based log file tables that are not owned by the ArcSDE administrator:

ALLOWSESSIONLOGFILE = TRUE

MAXSTANDALONELOGS = 0

LOGFILEPOOLSIZE = 0

Settings to control storage of session-based log file tables and indexes

There are several parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE table that control how or where log file tables are stored in the database. You do not have to set these to use session-based log files, but you can set them if you want to alter how the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION tables and indexes are stored in the database.

Which parameters are present and what they control depend on the DBMS being used.

For DB2, Informix, and Oracle, the following parameters control storage for session-based log file tables and indexes:

LD_INDEX_DATA_ID

LD_INDEX_ROW_ID

LD_STORAGE

LF_INDEXES

LF_STORAGE

SESSION_INDEX

SESSION_STORAGE

See DB2 DBTUNE configuration parameters, Informix DBTUNE configuration parameters, or Oracle DBTUNE configuration parameters for explanations of these parameters.

For PostgreSQL, the following parameters are used:

LD_INDEX_ALL

LD_STORAGE

LF_INDEX_ID

LF_INDEX_NAME

LF_STORAGE

SESSION_INDEX

SESSION_STORAGE

See PostgreSQL DBTUNE configuration parameters for explanations of these parameters.

For SQL Server, these parameters are used:

LD_INDEX_ALL

LD_STORAGE

LF_CLUSTER_ID

LF_CLUSTER_NAME

LF_INDEX_ID

LF_INDEX_NAME

LF_STORAGE

SESSION_TEMP_TABLE

The SESSION_TEMP_TABLE parameter must be set to 1 (TRUE) to allow the session-based log file table to be created in tempdb.

If you change the SESSION_TEMP_TABLE parameter to 0 (FALSE), the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION<SDE_ID> tables will be created in the connecting user's schema. This has implications for the privileges required for the user.

See SQL Server DBTUNE configuration parameters for explanations of these parameters.

Required user permissions to use session-based log files

Session-based log files are owned by the user who started the connecting session (unless you are using SQL Server with the default log file configuration that creates a table in tempdb). This means users need to have privileges that allow them to create the necessary database objects.

DB2	Informix	Oracle	PostgreSQL*
CONNECT CREATETAB IMPLICIT_SCHEMA	RESOURCE	CREATE SESSION CREATE TABLE CREATE TRIGGER CREATE SEQUENCE CREATE PROCEDURE	CONNECT USAGE and CREATE on the user's own schema

*For most PostgreSQL users, you will create a corresponding schema and grant the user AUTHORIZATION on the schema, which automatically confers USAGE and CREATE permissions on the schema.

If you use the recommended SQL Server settings, users only require the ability to connect to the database. However, if you change the SDE_dbtune SESSION_TEMP_TABLE parameter to 0, connecting users require CREATE TABLE permission in the database in addition to CONNECT privileges.

Most DBMSs grant CONNECT (CREATE SESSION in Oracle) privileges to all users by default; therefore, you only need to explicitly grant this permission if you have revoked it from PUBLIC.

Stand-alone log files are created by a session for each selection set the application needs to store.

Stand-alone log files generate the largest number of tables of all the log file options. Keep in mind that you need to configure enough space to store all these log file tables. The DBTUNE parameters SESSION_STORAGE and SESSION_INDEX allocate space for the tables and indexes of stand-alone log files in the majority of DBMSs.

When you want to use stand-alone log files

If you aren't concerned with granting CREATE permissions to all users, you can use stand-alone log file tables.

One advantage to stand-alone log file tables is that when a selection set is cleared, the SDE_LOGDATA table that held that selection will be truncated rather than deleted. Truncating can be performed more rapidly than a delete operation because no internal SQL statement has to be issued. However, there aren't many instances for which this gain in performance would outweigh the cost of creating and storing individual log file tables for each layer.

When you might not want to use stand-alone log files

If you have read-only users who connect to the database, you can't use stand-alone log files. As mentioned in the next section, the SDE_LOGDATA<SDE_ID> tables are dropped from the user's schema when the connection is terminated. They have to be re-created each time a layer's selection threshold is passed, so you cannot remove CREATE permissions from users if they are going to connect to the geodatabase.

Tables created for stand-alone log files

For each selection set above the selection threshold made by a session, a new SDE_LOGDATA<SDE_ID> table is created for each layer. This eliminates contention for the SDE_LOGDATA table. However, since a new table is created for each selection set and dropped when the session disconnects, a large number of CREATE TABLE and DROP TABLE SQL statements are generated.

The SDE_LOGFILES and SDE_LOGFILE_DATA tables are created per connection in the user's schema. The SDE_LOGFILES table stores the selection set properties, but the SDE_LOGFILE_DATA table isn't used.

When the selection set is no longer needed for the layers, the SDE_LOGDATA<SDE_ID> tables are truncated. The SDE_LOGDATA<SDE_ID> tables are dropped when the session disconnects. The SDE_LOGFILES and SDE_LOGFILE_DATA tables remain in the user's schema even after the user disconnects; however, the SDE_LOGFILES table is truncated.

Settings required to use stand-alone log files (nonpooled)

The parameter in the SERVER_CONFIG (sde_server_config in PostgreSQL and SQL Server) table that specifies the number of stand-alone log files that can be created is MAXSTANDALONELOGS. The default setting for MAXSTANDALONELOGS is 0, so if you want to use stand-alone log files, you must set the number of MAXSTANDALONELOGS to the number of stand-alone log files you want each user to be able to create.

The following settings are needed to create stand-alone log file tables that are not owned by the ArcSDE administrator:

MAXSTANDALONELOGS = <Maximum number of SDE_LOGDATA<SDE_ID> tables any user can create>

LOGFILEPOOLSIZE = 0

Stand-alone log files are used until the session's quota—defined by the MAXSTANDALONELOGS server configuration parameter—is exhausted. When the user runs out of stand-alone log files—in other words, if the application needs to simultaneously create more selection sets (log files) than MAXSTANDALONELOGS allows—ArcSDE will attempt to create session-based log files but only if ALLOWSESSIONLOGFILE is set to TRUE. If it can't create a session-based log file, it tries to create a shared log file. If a shared log file can't be created and the stand-alone log files are used up, ArcSDE returns an error.

See the section ArcSDE log file flowcharts for examples of the order in which log file types are used.

Settings to control storage of stand-alone log file tables and indexes

There are several parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE (sde_dbtune in PostgreSQL and SQL Server) table that control how or where log file tables are stored in the database. You do not have to set these to use stand-alone log files, but you can set them if you want to alter how the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_LOGDATA tables and indexes are stored in the database.

Which parameters are present and what they control depend on the DBMS being used.

For DB2, Informix, and Oracle, the following parameters control storage for stand-alone log file tables and indexes:

LD_INDEX_DATA_ID

LD_INDEX_ROW_ID

LD_STORAGE

LF_INDEXES

LF_STORAGE

SESSION_INDEX

SESSION_STORAGE

See DB2 DBTUNE configuration parameters, Informix DBTUNE configuration parameters, or Oracle DBTUNE configuration parameters for explanations of these parameters.

For PostgreSQL, the following parameters are used:

LD_INDEX_ALL

LD_STORAGE

LF_INDEX_ID

LF_INDEX_NAME

LF_STORAGE

SESSION_INDEX

SESSION_STORAGE

See PostgreSQL DBTUNE configuration parameters for explanations of these parameters.

For SQL Server, these parameters are used:

LD_INDEX_ALL

LD_STORAGE

LF_CLUSTER_ID

LF_CLUSTER_NAME

LF_INDEX_ID

LF_INDEX_NAME

LF_STORAGE

SESSION_TEMP_TABLE

The SESSION_TEMP_TABLE parameter must be set to 1 (TRUE) to allow the stand-alone log file tables to be created in tempdb.

If you change the SESSION_TEMP_TABLE parameter to 0 (FALSE), the SDE_LOGFILES, SDE_LOGFILE_DATA, and SDE_SESSION<SDE_ID> tables will be created in the connecting user's schema. This has implications for the privileges required for the user.

See SQL Server DBTUNE configuration parameters for explanations of these parameters.

Required user permissions to use stand-alone log files

DBMS user accounts using stand-alone log file tables have to have CREATE privileges for the necessary database objects. Unlike with shared log files, you can't revoke a user's privileges after the log file tables are created, because a new user-owned table per layer is created each time a session creates a large enough selection.

DB2	Informix	Oracle	PostgreSQL*	SQL Server**
CONNECT CREATETAB IMPLICIT_SCHEMA	RESOURCE	CREATE SESSION CREATE TABLE CREATE TRIGGER CREATE SEQUENCE CREATE PROCEDURE	CONNECT At least USAGE and CREATE on the user's own schema	CONNECT

*For most PostgreSQL users, you will create a corresponding schema and grant the user AUTHORIZATION on the schema, which automatically confers USAGE and CREATE permissions on the schema.

**If you leave SESSION_TEMP_TABLE set to 1, SQL Server users only require CONNECT privileges to the database. However, if you change the SDE_dbtune SESSION_TEMP_TABLE parameter to 0, connecting users require CREATE TABLE permission in the database in addition to CONNECT privileges.

Most DBMSs grant CONNECT (CREATE SESSION in Oracle) privileges to all users by default; therefore, you only need to explicitly grant this permission if you have revoked it from PUBLIC.

The ArcSDE administrator can create a pool of log files that can be checked out and used by other users. These can be either session-based or stand-alone log files. Shared log files cannot be checked out from an ArcSDE log file pool.

Using a pool of ArcSDE log files avoids having to grant users CREATE privileges in the database.

When you want to use pools of ArcSDE administrator-owned log files

You would use a pool of log files if you cannot give users the ability to create log file tables in their own schemas. Users still need to have permissions to create a session or connect to the database, though.

It is a more efficient use of pool resources to use session-based log files in the pool because session-based log files will write multiple selection sets to a single table, whereas stand-alone log files use one table for each eligible selection set.

When you might not want to use pools of ArcSDE administrator-owned log files

Overall, using pools of log files requires slightly more maintenance because you must estimate the number of necessary log file tables, and you may find yourself adjusting the size of the pool or the number of pools used. Keep in mind that a large log file pool or a large number of log file pools can have a negative impact on performance.

Tables created for pools of ArcSDE administrator-owned log files

The value set for the LOGFILEPOOLSIZE parameter in the SERVER_CONFIG table determines the number of SDE_LOGPOOL_<table_ID> tables created in the ArcSDE administrative user's schema. For example, if you set LOGFILEPOOLSIZE to 5, the following tables are created in the schema of the ArcSDE administrator:

SDE_LOGPOOL_1

SDE_LOGPOOL_2

SDE_LOGPOOL_3

SDE_LOGPOOL_4

SDE_LOGPOOL_5

An additional table in the ArcSDE administrator's schema, SDE_LOGFILE_POOL, records the SDE_ID for the ArcSDE session and a table ID. The <table_ID> in the name of the SDE_LOGPOOL table corresponds to the value in the table_ID column of the SDE_LOGFILE_POOL table.

If you use a pool of session-based log files, each session that creates a selection exceeding the selection threshold adds one record to the SDE_LOGFILE_POOL table and the session is allocated to one of the SDE_LOGPOOL_<table_ID> tables. If additional log files are created by the same session—for example, a second selection set of 300 records is created in one ArcMap session—the new log files (selection set) are added to the same SDE_LOGPOOL table.

When log files are cleared, the SDE_LOGPOOL table that is checked out to the session is truncated. For example, if the second selection set in the ArcMap session is cleared, the 300 records are removed from the SDE_LOGPOOL table, but the records for the first selection set remain. When the first selection set is cleared, these records are removed from the SDE_LOGPOOL table.

If you use a pool of stand-alone log files, each log file (selection set of the required size) creates a new record in the SDE_LOGFILE_POOL table and uses one of the SDE_LOGPOOL tables. For example, if in a single ArcMap session, you selected (1) from a feature class that stored information about businesses, all the businesses licensed to serve food and (2) from a feature class that stored storm drain information, all catch basins located within a kilometer of a business that served food, there would be two records added to the SDE_LOGFILE_POOL table: one for the selection set of businesses and one for the selection set of catch basins. Each selection set would be assigned its own SDE_LOGPOOL table.

As a log file (selection set) is cleared, the corresponding SDE_LOGPOOL table is truncated.

Settings required to use ArcSDE administrator-owned pools of log files

The settings in the SERVER_CONFIG table that specifically affect pools of log files are LOGFILEPOOLSIZE and HOLDLOGPOOLTABLES.

As mentioned in the previous section, to create a pool of log files, set the configuration parameter LOGFILEPOOLSIZE to the number of log files (in other words, the number of SDE_LOGPOOL tables) that you determine need to be created. This number should reflect the number of sessions that will connect to your server in addition to the stand-alone log files, if allowed.

To calculate the total number of log files you should set for the log file pool, use the following formulas:

• If session log files are allowed but not stand-alone log files
LOGFILEPOOLSIZE = total sessions expected
For example, if MAXSTANDALONELOGS is set to 0, ALLOWSESSIONLOGFILE is set to TRUE, and you expect no more than 30 connections to the geodatabase at any one time, set LOGFILEPOOLSIZE to 30.
• If stand-alone log files are allowed but not session log files
LOGFILEPOOLSIZE = MAXSTANDALONELOGS * total sessions expected
For instance, if MAXSTANDALONELOGS is set to 5, ALLOWSESSIONLOGFILE is set to FALSE, and you estimate no more than 10 connections will be made to the geodatabase at any one time, set LOGFILEPOOLSIZE to 50.
LOGFILEPOOLSIZE = 5 * 10
• If both stand-alone log files and session log files are allowed
LOGFILEPOOLSIZE = (MAXSTANDALONELOGS + 1) * total sessions expected
For instance, if MAXSTANDALONELOGS is set to 8, ALLOWSESSIONLOGFILE is set to true, and you estimate there will be no more than 20 connections to the database at any one time, you would set LOGFILEPOOLSIZE to 180.
LOGFILEPOOLSIZE = (8 + 1) * 20

If the pool is exhausted and another log file table is needed, ArcSDE will attempt to create it in the user's schema. If the log file table cannot be created in the user's schema, an error is returned.

The SDE_LOGPOOL_<table_ID> tables are created or dropped whenever the LOGFILEPOOLSIZE parameter is changed. In the previous example, when LOGFILEPOOLSIZE is set to 180, 180 SDE_LOGPOOL_<table_ID> tables are created. If you change the LOGFILEPOOLSIZE parameter to 100, 80 of those tables will be dropped.

The other log file pool parameter, HOLDLOGPOOLTABLES, determines when an SDE_LOGPOOL table gets returned to the pool and can be used by other users. If HOLDLOGPOOLTABLES is set to TRUE (the default value), records remain in the SDE_LOGFILE_POOL table and SDE_LOGPOOL tables stay locked until the connecting session is terminated. If HOLDLOGPOOLTABLES is set to FALSE, the log file tables are released and the SDE_LOGFILE_POOL table is truncated whenever the selection set is no longer needed. This behavior is the same for pools of stand-alone and session-based log files.

Settings to control storage of ArcSDE administrator-owned pools of log file tables and indexes

There are only a few parameters under the LOGFILE_DEFAULTS keyword of the DBTUNE (sde_dbtune in PostgreSQL and SQL Server) table that control how the SDE_LOGPOOL<SDE_ID> tables and their indexes are stored.

ArcSDE for PostgreSQL and SQL Server use the LD_STORAGE and LD_INDEX_ALL parameters in the sde_dbtune table to set storage for the SDE_LOGPOOL<SDE_ID> tables and their indexes. These two parameters also control the storage of the SDE_LOGFILE_DATA table and index. See PostgreSQL DBTUNE configuration parameters or SQL Server DBTUNE configuration parameters for explanations of these parameters.

In ArcSDE geodatabases for Oracle, Informix, and DB2, the LD_STORAGE, LD_INDEX_ROWID, and LD_INDEX_DATA_ID DBTUNE parameters are used to set storage for the SDE_LOGPOOL<SDE_ID> tables and their indexes. These three parameters also control the storage of the SDE_LOGFILE_DATA table and indexes. See Oracle DBTUNE configuration parameters, Informix DBTUNE configuration parameters, or DB2 DBTUNE configuration parameters for explanations of these parameters.

You do not have to set these to use pools of log file tables, but you can set them if you want to alter how the SDE_LOGPOOL<SDE_ID> tables and indexes are stored in the database.

Required user permissions to use ArcSDE administrator-owned pools of log files

To utilize the log file tables in the pool, users only require the ability to connect to the database and use the objects in the ArcSDE administrator's schema.

DB2	Informix	Oracle	PostgreSQL*	SQL Server
CONNECT	CONNECT	CREATE SESSION	CONNECT USAGE on the sde schema	CONNECT

*If your PostgreSQL database is used exclusively for your geodatabase, you will usually grant USAGE permission on the sde schema to PUBLIC to avoid having to grant it to every individual role or group. USAGE on the sde schema is necessary for users to access the geodatabase.

The following diagram demonstrates the order in which ArcSDE will try to use log file tables.

It is recommended you stick with the default log file settings for your DBMS, but if you change your log file configuration parameters from the default values, be aware there are situations in which you might end up using more than one type of log file at a time. For example, if you set the following parameters:

MAXSTANDALONELOGS=20

ALLOWSESSIONLOGFILE=true

LOGFILEPOOLSIZE=0

and all 20 log files are in use, when the request for another log file comes in, a session-based log file will be used. If you have the following settings in a SQL Server database, that session-based log file table will be created in tempdb:

MAXSTANDALONELOGS=20

ALLOWSESSIONLOGFILE=true

LOGFILEPOOLSIZE=0

SESSION_TEMP_TABLE=1

Similarly, if you have these settings and 15 log files are needed simultaneously, all 10 of the log file tables in the pool will be used plus 5 shared log files will be created.

MAXSTANDALONELOGS=0

ALLOWSESSIONLOGFILE=true

LOGFILEPOOLSIZE=10

If you have the same settings in a SQL Server database plus have SESSION_TEMP_TABLE set to 1, the 10 log file tables in the pool will be used first, then the next 5 session-based log file tables will be created in tempdb.