Skip to main content

Search

Welcome to Tibero GTS!

Windows 7.2.2 DB nomount Startup Failure Issue

Document Type | Troubleshooting

Category | Installation

Applicable Product Versions | 7FS02, 7FS02PS

Document Number | TINTS013

 

Issue

After DB nomount startup, the startup fails and an Internal Error occurs in the Slog.
The error codes recorded in the Slog are as follows.
[2024-12-04T09:26:14.070000] [FRM-00] [I] time scale factor: (2496.629695->2497), real: 3617227 (usec) -> calculated: 3616015 (usec)

[2024-12-04T09:26:14.070000] [FRM-00] [I] min sleep time: 0 usec

[2024-12-04T09:26:14.515000] [CLB-00] [I] buffer cache pool initialization: total_wscnt=48, total_blkcnt=213360, blkcnt_per_ws=4445, cache_size_per_ws=34M

[2024-12-04T09:26:14.515000] [CLB-00] [I] Default/Keep/Recycle Blocks=213360/0/0, WS = 48/0/0

[2024-12-04T09:26:14.548000] [TXS-00] [I] init l1cache: bucket_size=1024/1024

[2024-12-04T09:26:14.549000] [TXU-00] [I] xa init. pending_tx_cnt: 0

[2024-12-04T09:26:14.568000] [FRM-00] [I] Server is running at NOMOUNT mode (bootmode : NOMOUNT, bootflag : 0)

 

... omitted ..

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #0) LC. slave alloc: idx=0, init size=33554432, max size = 206682572, root alloc: available size=413335552, used size=33554432

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #0) DD. slave alloc: idx=0, init size=33554432, max size = 206682572, root alloc: available size=413335552, used size=67108864

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #0) SLAB. slave alloc: idx=0, init size=33554432, max size = 206682572, root alloc: available size=413335552, used size=100663296

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #0) MISC. slave alloc: idx=0, init size=8388608, max size = 330692115, root alloc: available size=413335552, used size=109051904

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #1) MISC. slave alloc: idx=1, init size=8388608, max size = 330692115, root alloc: available size=413335552, used size=117440512

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #2) MISC. slave alloc: idx=2, init size=8388608, max size = 330692115, root alloc: available size=413335552, used size=125829120

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #3) MISC. slave alloc: idx=3, init size=8388608, max size = 330692115, root alloc: available size=413335552, used size=134217728

[2024-12-04T09:26:14.620000] [ALC-00] [I] root_alloc for initializing (SHP slave allocator #0) LTERM. slave alloc: idx=0, init size=33554432, max size = 330692115, root alloc: available size=413335552, used size=167772160

[2024-12-04T09:26:14.634000] [FRM-00] [I] MONP(tbsvr) is ready : tid(0), ospid(16004)

[2024-12-04T09:26:14.651000] [COM-81] [I] Internal Error with condition '!"Error entring TRY block with spinlock."' (rv_slave.c:2310) (pid=16004, sessid=81, tid=81, os_thr_id=22908)

 

Cause

In Windows environments, the MAX_SESSION_CNT value causes the _SYSTEM_ROOT_ALLOCATOR_CNT parameter value to increase. By default, the _SYSTEM_ROOT_ALLOCATOR_CNT default value is set to MAX_SESSION_CNT / 2. Because of this, the logic in the tb_root_malloc function initializes a buffer of that size, and if MAX_SESSION_CNT exceeds 256, a buffer larger than 128 is initialized, which can cause memory corruption.
 
The issue occurs because there is insufficient exception handling for this.
 
 
 

Solutions

1. Apply the patch to resolve the issue. (Applied patch: 336017a)

This patch modifies the value so that _SYSTEM_ROOT_ALLOCATOR_CNT does not exceed 128. 

Note
Apply the patch through technical support provided by Tmax Tibero.
 

2. You can attempt to resolve the error by setting a workaround.

(You can bypass the issue by applying one of the two methods below.)

  • Set MAX_SESSION_COUNT to a value of 256 or less.
  • Set _SYSTEM_ROOT_ALLOCATOR_CNT to a value of 128 or less.
     
After configuration, you can verify if the issue has been resolved using the methods below.
 
[Direct Verification]
 On a Windows machine, check if the boot process proceeds normally with MAX_SESSION_COUNT=500. (Even if boot fails, it should fail while leaving logs.)
 
[Indirect Verification]
After booting with MAX_SESSION_COUNT set to 256 or more, check if _SYSTEM_ROOT_ALLOCATOR_CNT is fixed at 128 by running select * from _vt_parameters.
Note
This applies not only to Tibero7.2.2 Windows but also to all Windows Servers with FS02_312239a applied.

 

 

 

 

Related to