DATA STORE IS IN FLUX BY PROCESS

Hello:
I am receiving constantly this message on my datastore in linux:
DATA STORE IS IN FLUX BY PROCESS
What is the meannig of this message... "DATA STORE IS IN FLUX BY PROCESS"?
I have not found data for this error.
Thanks.

In Timesten, all datastore connect and disconnect requests are mediated by the TimesTen main daemon. Think of the 'flux' for a datastore as a type of mutex implemented within the main daemon to avoid rce conditions when ,multiple processes or threads are trying to conhnect / disconnect to / from the same datastore at the same time. Essentially, all the connect and disconnects requests for a datastore must be serialised via the flux. If you are seeing a lot of 'waiting for flux' type messages this may indicate one or more of the folllowing:
1. You have an excessive rate of connect / disconnect requests occurring. Connect / disconnect is expensive and relatively slow; applications should use persistent / long lived connections as much as possible.
2. Some connect / disconnect requests are taking much longer than expected. Perhaps the system is under heavy load and/or paging excessively.
Chris

Similar Messages

838 Cannot get data store shared memory segment error in Timesten

Hi Chris,
This is shalini. I have mailed u for last two days reg this issue. You asked me about few details. Here the answer is,
1, Have u modified anything after timesten installation? - No. I didnt change anything .
2, What are the three values under physical memory? - Total - 2036 MB ,Cached - 1680 MB ,Free - 12 MB
3, ttmesg.log and tterrors.log? -
tterrors.log::
12:48:58.83 Warn: : 1016: 3972 Connecting process reports creation failure
ttmesg.log::
12:48:58.77 Info: : 1016: maind got #12.14, hello: pid=3972 type=library payload=%00%00%00%00 protocolID=TimesTen 11.2.1.3.0.tt1121_32 ident=%00%00%00%00
12:48:58.77 Info: : 1016: maind: done with request #12.14
12:48:58.77 Info: : 1016: maind got #12.15 from 3972, connect: name=c:\timesten\tt1121_32\data\my_ttdb\my_ttdb context= 266e900 user=InstallAdmin pass= dbdev= logdev= logdir=c:\timesten\tt1121_32\logs\my_ttdb grpname= access=%00%00%00%00 persist=%00%00%00%00 flags=@%00%00%01 newpermsz=%00%00%00%02 newtempsz=%00%00%00%02 newpermthresh=Z%00%00%00 newtempthresh=Z%00%00%00 newlogbufsz=%00%00%00%02 newsgasize=%00%00%00%02 newsgaaddr=%00%00%00%00 autorefreshType=%ff%ff%ff%ff logbufparallelism=%00%00%00%00 logflushmethod=%00%00%00%00 logmarkerinterval=%00%00%00%00 connections=%03%00%00%00 control1=%00%00%00%00 control2=%00%00%00%00 control3=%00%00%00%00 ckptrate=%06%00%00%00 connflags=%00%00%00%00 newlogfilesz=%00%00@%01 skiprestorecheck=%00%00%00%00 realuser=InstallAdmin conn_name=my_ttdb ckptfrequency=X%02%00%00 ckptlogvolume=%14%00%00%00 recoverythreads=%03%00%00%00 reqid=* plsql=%ff%ff%ff%ff receiverThreads=%00%00%00%00
12:48:58.77 Info: : 1016: 3972 0266E900: Connect c:\timesten\tt1121_32\data\my_ttdb\my_ttdb a=0x0 f=0x1000040
12:48:58.77 Info: : 1016: permsize=33554432 tempsize=33554432
12:48:58.77 Info: : 1016: logbuffersize=33554432 logfilesize=20971520
12:48:58.77 Info: : 1016: permwarnthresh=90 tempwarnthresh=90 logflushmethod=0 connections=3
12:48:58.77 Info: : 1016: ckptfrequency=600 ckptlogvolume=20 conn_name=my_ttdb
12:48:58.77 Info: : 1016: recoverythreads=3 logbufparallelism=0
12:48:58.77 Info: : 1016: plsql=0 sgasize=33554432 sgaaddr=0x00000000
12:48:58.77 Info: : 1016: control1=0 control2=0 control3=0
12:48:58.79 Info: : 1016: ckptrate=6 receiverThreads=0
12:48:58.79 Info: : 1016: 3972 0266E900: No such data store
12:48:58.79 Info: : 1016: daDbConnect failed
12:48:58.79 Info: : 1016: return 1 833 'no such data store!' arg1='c:\timesten\tt1121_32\data\my_ttdb\my_ttdb' arg1type='S' arg2='' arg2type='S'
12:48:58.79 Info: : 1016: maind: done with request #12.15
12:48:58.79 Info: : 1016: maind got #12.16 from 3972, create: name=c:\timesten\tt1121_32\data\my_ttdb\my_ttdb context= 266e900 user=InstallAdmin pass= dbdev= logdev= logdir=c:\timesten\tt1121_32\logs\my_ttdb grpname= persist=%00%00%00%00 access=%00%00%00%00 flags=@%00%00%01 permsize=%00%00%00%02 tempsize=%00%00%00%02 permthresh=Z%00%00%00 tempthresh=Z%00%00%00 logbufsize=%00 %00%02 logfilesize=%00%00@%01 shmsize=8%f4%c9%06 sgasize=%00%00%00%02 sgaaddr=%00%00%00%00 autorefreshType=%01%00%00%00 logbufparallelism=%00%00%00%00 logflushmethod=%00%00%00%00 logmarkerinterval=%00%00%00%00 connections=%03%00%00%00 control1=%00%00%00%00 control2=%00%00%00%00 control3=%00%00%00%00 ckptrate=%06%00%00%00 connflags=%00%00%00%00 inrestore=%00%00%00%00 realuser=InstallAdmin conn_name=my_ttdb ckptfrequency=X%02%00%00 ckptlogvolume=%14%00%00%00 recoverythreads=%03%00%00%00 reqid=* plsql=%00%00%00%00 receiverThreads=%00%00%00%00
12:48:58.79 Info: : 1016: 3972 0266E900: Create c:\timesten\tt1121_32\data\my_ttdb\my_ttdb p=0x0 a=0x0 f=0x1000040
12:48:58.79 Info: : 1016: permsize=33554432 tempsize=33554432
12:48:58.79 Info: : 1016: logbuffersize=33562624 logfilesize=20971520
12:48:58.80 Info: : 1016: shmsize=113898552
12:48:58.80 Info: : 1016: plsql=0 sgasize=33554432 sgaaddr=0x00000000
12:48:58.80 Info: : 1016: permwarnthresh=90 tempwarnthresh=90 logflushmethod=0 connections=3
12:48:58.80 Info: : 1016: ckptfrequency=600 ckptlogvolume=20 conn_name=my_ttdb
12:48:58.80 Info: : 1016: recoverythreads=3 logbufparallelism=0
12:48:58.80 Info: : 1016: control1=0 control2=0 control3=0
12:48:58.80 Info: : 1016: ckptrate=6, receiverThreads=1
12:48:58.80 Info: : 1016: creating DBI structure, marking in flux for create by 3972
12:48:58.82 Info: : 1016: daDbCreate: about to call createShmAndSem, trashed=-1, panicked=-1, shmSeq=1, name c:\timesten\tt1121_32\data\my_ttdb\my_ttdb
12:48:58.82 Info: : 1016: marking in flux for create by 3972
12:48:58.82 Info: : 1016: create.c:338: Mark in-flux (now reason 1=create pid 3972 nwaiters 0 ds c:\timesten\tt1121_32\data\my_ttdb\my_ttdb) (was reason 1)
12:48:58.82 Info: : 1016: maind: done with request #12.16
12:48:58.83 Info: : 1016: maind got #12.17 from 3972, create complete: name=c:\timesten\tt1121_32\data\my_ttdb\my_ttdb context= 266e900 connid=%00%08%00%00 success=N
12:48:58.83 Info: : 1016: 3972 0266E900: CreateComplete N c:\timesten\tt1121_32\data\my_ttdb\my_ttdb
12:48:58.83 Warn: : 1016: 3972 Connecting process reports creation failure
12:48:58.83 Info: : 1016: About to destroy SHM 560
12:48:58.83 Info: : 1016: maind: done with request #12.17
12:48:58.83 Info: : 1016: maind 12: socket closed, calling recovery (last cmd was 17)
12:48:58.85 Info: : 1016: Starting daRecovery for 3972
12:48:58.85 Info: : 1016: 3972 ------------------: process exited
12:48:58.85 Info: : 1016: Finished daRecovery for pid 3972.
I think "Connecting process reports creation failure" is the error shown.
4, DSN Attributes? -
earlier, i used my_ttdb which is the SYSTEM DSN , and i tried by creating a user DSN, still it is not working. I will give the my_ttdb dsn attributes.
I am unable to attach the screenshots in this message. Is there anyway to attach it. I should not send the reply through mail from my company, so only sent this message. You can reply to my mailbox id.
Chris or Anybody can please reply to this below message.
I am having a table called Employee. I have created a view called emp_view.
create view emp_view as
select /*+ INDEX (Employee emp_no) */
emp_no,emp_name
from Employee;
we have another index on Employee table called emp_name.
I need to use the emp_name index in emp_view like below.
select /*+ INDEX (<from employee tables> emp_name) */
emp_no
from emp_view
where emp_name='SSS';
in the index i tried /*+ INDEX (emp_view.Employee emp_name) */ But it is still taking the index used in emp_view view ie emp_no.. Anyone can u please help me to resolve this issue.
Edited by: user12154813 on Nov 3, 2009 4:21 AM

DSN Attributes for the two paths u gave are mentioned below.
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\mt_ttdb:
(Default) - (value not set)
AssertDlg - 1
AutoCreate -1
AutorefreshType -1
CacheGridEnable -0
CacheGridMsgWait -60
CatchupOverride -0
CkptFrequency -600
CkptLogVolume -20
CkptRate -6
ConnectionCharacterSet -US7ASCII
Connections -3
Control1 -0
Control2 -0
Control3 -0
DatabaseCharacterSet -US7ASCII
DataStore - C:\TimesTen\tt1121_32\Data\my_ttdb\my_ttdb
DDLCommitBehavior -0
Description - My Timesten Data store
Diagnostics -1
Driver - C:\TimesTen\tt1121_32\bin\ttdv1121.dll
DuplicateBindMode -0
DurableCommits -0
DynamicLoadEnable -1
DynamicLoadErrorMode -0
ExclAccess -0
ForceConnect -0
InRestore -0
Internal1 -0
Isolation -1
LockLevel -0
LockWait -10.0
LogAutoTruncate -1
LogBuffSize -0
LogBufMB -32
LogBufParallelism -0
LogDir -C:\TimesTen\tt1121_32\Logs\my_ttdb
LogFileSize -20
LogFlushMethod -0
Logging -1
LogMarkerInterval -0
LogPurge -1
MatchLogOpts -0
MaxConnsPerServer -4
NLS_LENGTH_SEMANTICS -BYTE
NLS_NCHAR_CONV_EXCP -0
NLS_SORT -BINARY
NoConnect -0
Overwrite -0
PassThrough -0
PermSize -32
PermWarnThreshold -0
PLSQL - value (-1)
PLSQL_CODE_TYPE -INTERPRETED
PLSQL_CONN_MEM_LIMIT - 100
PLSQL_MEMORY_SIZE - 32
PLSQL_OPTIMIZE_LEVEL - 2
PLSQL_TIMEOUT - 30
Preallocate -0
PrivateCommands -0
QueryThreshold - value (-1)
RACCallback -1
ReadOnly -0
ReceiverThreads -0
RecoveryThreads -3
SkipRestoreCheck -0
SMPOptLevel - value(-1)
SQLQueryTimeout - value(-1)
Temporary -0
TempSize -32
TempWarnThreshold - 0
ThreadSafe -1
TransparentLoad- value(-1)
TypeMode -0
WaitForConnect -1
XAConnection -0
HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\my_test:
existing values changed from the above dsn attributes:
TypeMode - value(-1)
RecoveryThreads -0
MaxConnsPerServer -5
LogFileSize -4
LogDir -C:\TimesTen\tt1121_32\Logs\my_test
DataStore - C:\TimesTen\tt1121_32\data\my_test\my_test
DatabaseCharacterSet -AL32UTF8
ConnectionCharacterSet -AL32UTF8
CkptFrequency - value(-1)
CkptLogVolume - value(-1)
CkptRate -value(-1)
Connections -0
CacheGridEnable -1
newly added values:
ServerStackSize - 10
ServersPerDSN -2
other attributes are same for both the dsn's.
Please reply as soon as possible.
Thanks,
Shalini.
Edited by: user12154813 on Nov 3, 2009 11:34 PM
Edited by: user12154813 on Nov 3, 2009 11:37 PM

TtRestoring a Data Store w/ a Large PermSize to a Smaller PermSize

If have a backup of a data store created by ttBackup. I'd like to restore that data store into a data store with a smaller PermSize. The original data should fit in the new data store. However, I'm encountering errors doing this.
I've done the following:
- Ran ttBackup on the source data store.
- The source data store has a PermSize of 16 Gb, but it's backup file is about 4.5 Gbytes.
- On the target machine, I created an entry in the odbc.ini for the new data store, but with a PermSize=6144
- On the target machine, I then run ttIsql target_dsn_name
- This works okay and ipcs shows a shared memory segment with a size that correlates to the PermSize=6144.
- Then that data store is ttDestroy'ed to get it out of the way.
- Next I ran: ttRestore -fname source_dsn_name -connstr "DSN=target_dsn_name;Preallocate=1;PermSize=6144;TempSize=120" -dir . -noconn
- This succeeds, but only because "-noconn" was specified.
- When I 1st try to connect to the datastore by running: ttIsql "DSN=target_dsn_name;PermSize=6144;TempSize=120"
- It fails with the following error:
836: Cannot create data store shared-memory segment, error 22
703: Subdaemon connect to data store failed with error TT836
- The tterror.log contains:
19:59:05.54 Err : : 3810: TT14000: TimesTen daemon internal error: Error 22 creating shared segment, KEY 0x0401a8b2
19:59:05.54 Err : : 3810: -- OS reports invalid shared segment size
19:59:05.54 Err : : 3810: -- Confirm that SHMMAX kernel parameter is set > datastore size
19:59:05.54 Err : : 3820: subd: Error identified in [sub.c: line 3188]
19:59:05.54 Err : : 3820: subd: (Error 836): TT0836: Cannot create data store shared-memory segment, error 22 -- file "db.c", lineno 9342, procedure "sbDbConnect"
19:59:05.54 Err : : 3820: file "db.c", lineno 9342, procedure "sbDbConnect"
19:59:05.54 Warn: : 3820: subd: connect trouble, rc 1, reason 836
19:59:05.54 Err : : 3820: Err 836: TT0836: Cannot create data store shared-memory segment, error 22 -- file "db.c", lineno 9342, procedure "sbDbConnect"
19:59:05.54 Err : : 3810: TT14000: TimesTen daemon internal error: Could not send 'manage' request to subdaemon rc 400 err1 703 err2 836
19:59:06.45 Warn: : 3810: 3820 ------------------: subdaemon process exited
Note that on the target machine total shared memory is configured for only 10 Gb, which is smaller than the size of the original data store.

Hi Brian,
ttRestore cannot be used for this purpose. The restored datastroe will always have the PermSize that was in effect when it was backed up. You cannot shrink an existing datastore. If you need to move the tables and data to a store with a smaller PermSize (assuming they will fit of course) then you need to use ttMigrate instead.
Chris

703: Subdaemon connect to data store failed with error TT9999

All,
I'm getting the following error whilst trying to connect to a TimesTen DB:
connect "DSN=my_cachedb";
703: Subdaemon connect to data store failed with error TT9999
In the tterrors.log:
16:39:24.71 Warn: : 2568: 3596 ------------------: subdaemon process exited
16:39:24.71 Warn: : 2568: 3596 exited while connected to data store '/u01/ttdata/datastores/my_cachedb' shm 33554529 count=1
16:39:24.71 Warn: : 2568: daRecovery: subdaemon 3596, managing data store, failed: invalidate (failcode=202)
16:39:24.71 Warn: : 2568: Invalidating the data store (failcode 202, recovery for 3596)
16:39:24.72 Err : : 2568: TT14000: TimesTen daemon internal error: Could not send 'manage' request to subdaemon rc -2 err1 703 err2 9999
16:39:24.72 Warn: : 2568: 3619 Subdaemon reports creation failure
16:39:24.72 Err : : 2568: TT14000: TimesTen daemon internal error: Deleting 3619/0x1558650/'/u01/ttdata/datastores/my_cachedb' - from association table - not found
16:39:24.72 Err : : 2568: TT14004: TimesTen daemon creation failed: Could not del from dbByPid internal table
16:39:24.81 Warn: : 2568: child process 3596 terminated with signal 11
16:39:25.09 Err : : 2568: TT14000: TimesTen daemon internal error: daRecovery for 3619: No such data store '/u01/ttdata/datastores/my_cachedb'
I've checked and the datastore does exist and is owned by the timesten UNIX user.
ttversion:
TimesTen Release 11.2.2.2.0 (64 bit Linux/x86_64) (tt1122:53396) 2011-12-23T09:26:28Z
Instance admin: timesten
Instance home directory: /home/timesten/TimesTen/tt1122
Group owner: timesten
Daemon home directory: /home/timesten/TimesTen/tt1122/info
PL/SQL enabled.
Datastore definition from sys.odbc.ini:
[my_cachedb]
Driver=/home/timesten/TimesTen/tt1122/lib/libtten.so
DataStore=/u01/ttdata/datastores/my_cachedb
LogDir=/u01/ttdata/logs
PermSize=40
TempSize=32
DatabaseCharacterSet=AL32UTF8
OracleNetServiceName=testdb
Kernel parameters from sysctl -a:
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
Memory / SWAP:
MemTotal: 2050784 kB
SWAP: /dev/mapper/VolGroup00-LogVol01 partition 4095992
I'm new to TimesTen and I'm planning on evaluationg it to see if it could solve an issue we're having. Any suggestions would be much appreciated.
Thanks,
Ian.

Hi Ian,
Can you please answer the following / provide the following information:
1. What are your kernel parameters relating to semaphores set to? Is anything else on the mahcine using significant numbers of semaphores?
2. Please provide the output of the following shell commands:
ls -ld /u01
ls -ld /u01/ttdata
ls -ld /u01/ttdata/datastores
ls -ld /u01/ttdata/logs
3. Please provide an excerpt of the detailed message log (ttmesg.log) between around 16:38 and 16:40 (i.e. from a little while before the problem until after the problem).
Thanks,
Chris

Changing the Target data store dynamically

Hi,
I have a requirement to load same kind of data into 12 different target tables. Client maintains data in period vise, i.e. Jan data in a table TABLE_01, Feb data in TABLE_02, Dec data in TABLE_12 etc. The structures of all these tables are same.
My program will process only one period’s data at a time and processed data will be loaded into a table TABLE_SRC. After this, according to the processing period, I need to post the data into the target tables TABLE_01, TABLE_02 etc. i.e. if the data is for period Jan then to TABLE_01, data is for period Feb then to TABLE_02 and so on.
For accomplishing the same, I need to create 12 different interfaces. So is there any way to accomplish the same using a single interface by changing the target data store dynamically? I am looking for a solution other that creating procedures.
Any Help is appreciated.
Thanks in advance.
DJ

Yes, it is possible....
1) at the target datastore use a variable at resource
2) create a query that returns all target tables in a source tab (procedure step)
3) at target tab, call the interface scenario send the query result as parameter.
That will allow you execute the same interface for disitnct targets.
Does it help you?

How to determine what's using data store temp space?

How can one determine what's using data store temp space? We are interested to know what structures are occupying space in temp space and if possible what pid/process connected to TimesTen created them.
Also, is there a procedure that will work if temp space is full?
Recently one of our data stores ran of space. We we're unable to run commands like "monitor", "select * from monitor", "select count(*) from my_application_table", etc. These commands failed because they required temp space to run and temp space was full. We killed the application processes, this in turned freed up temp space, then we were able to run these queries.
Ideally, we'd like to have a procedure to figure out what's using temp space when temp space is full.
The other thing we could do is periodically monitor temp space prior to it filling to determine what's using temp space.

That was my original thought, but once you click the slider track or thumb, and then enter a value in the text control, the clickTarget on the change event envoked by the change to the bound data (after entering a value in the text control) will be whatever slider element had last been clicked. If you've never clicked the slider, clickTarget=null. But once you've clicked the slider the clickTarget always has a value of "thumb" or "track", regardless of what triggered the change event.

Cannot attach data store shared-memory segment using JDBC (TT0837) 11.2.1.5

Hi,
I found the thread Cannot attach data store shared-memory segment using JDBC (TT0837) but it can't help me out.
I encounter this issue in Windows XP, and application gets connection from jboss data source.
url=jdbc:timesten:direct:dsn=test;uid=test;pwd=test;OraclePWD=test
username=test
password=test
Error information:
java.sql.SQLException: [TimesTen][TimesTen 11.2.1.5.0 ODBC Driver][TimesTen]TT0837: Cannot attach data store
shared-memory segment, error 8 -- file "db.c", lineno 9818, procedure "sbDbConnect"
at com.timesten.jdbc.JdbcOdbc.createSQLException(JdbcOdbc.java:3295)
at com.timesten.jdbc.JdbcOdbc.standardError(JdbcOdbc.java:3444)
at com.timesten.jdbc.JdbcOdbc.standardError(JdbcOdbc.java:3409)
at com.timesten.jdbc.JdbcOdbc.SQLDriverConnect(JdbcOdbc.java:813)
at com.timesten.jdbc.JdbcOdbcConnection.connect(JdbcOdbcConnection.java:1807)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:303)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:159)
I am confused that if I use jdbc, there is no such error.
Connection conn = DriverManager.getConnection("url", "username", "password");
Regards,
Nesta

I think error 8 is
net helpmsg 8
Not enough storage is available to process this command.
If I'm wrong I'm happy to be corrected. If you reduce the PermSize and TempSize of the datastore (just as a test) does this allow JBOSS to load it?
You don't say whether this is 32bit or 64bit Windows. If it's the former, the following information may be helpful.
"Windows manages virtual memory differently than all other OSes. The way Windows sets up memory for DLLs guarantees that the virtual address space of each process is badly fragmented. Other OSes avoid this by densely packing shared libraries.
A TimesTen database is represented as a single contiguous shared segment. So for an application to connect to a database of size n, there must be n bytes of unused contiguous virtual memory in the application's process. Because of the way Windows manages DLLs this is sometimes challenging. You can easily get into a situation where simple applications that use few DLLs (such as ttIsql) can access a database fine, but complicated apps that use many DLLs can not.
As a practical matter this means that TimesTen direct-mode in Windows 32-bit is challenging to use for those with complex applications. For large C/C++ applications one can usually "rebase" DLLs to reduce fragmentation. But for Java based applications this is more challenging.
You can use tools like the free "Process Explorer" to see the used address ranges in your process.
Naturally, 64-bit Windows basically resolves these issues by providing a dramatically larger set of addresses."

ISE Alarm : Warning : Session directory write failed : [TimesTen][TimesTen 11.2.2.2.0 ODBC Driver][TimesTen]TT0846: Data store connection invalid or not current -- file "dbAPI.c"; lineno 7475; procedure "sb_connLatchAcquire"

I got this message about 20 times:
Log Collection Error
Details :
Session directory write failed : [TimesTen][TimesTen 11.2.2.2.0 ODBC Driver][TimesTen]TT0846: Data store connection invalid or not current -- file "dbAPI.c"; lineno 7475; procedure "sb_connLatchAcquire"
Description :
The ISE M&T collector process is unable to persist the audit logs generated from the Policy Service nodes
Suggested Actions :
This will not impact the actual functionality of the Policy Service nodes, Please contact TAC"
It started after I've added a third DNS Server and did not reboot the whole appliance, but just all services....
Does anyone know what really might triggered this? After rebooting ISE everything was ok again. But I couldn't find anything in ISE's logs
KR

I did a reboot and the problem was solved. I got the message when I tried to stop ISE while all services were just about to get up.
ISE Version: 1.2.0.899

TT0846: Data store connection invalid or not current

In one of our environments we started getting TT0846 error randomly.
Everytime we get this error we have to restart our application to reconnect to datasore.
When we checked the error logs, we found the following:
08:32:00.56 Err : : 20084: 20089/0x198ede80: XXX: fstat returned with info uid=670 gid=673 mode=drwxr-xr-x size=12288
08:32:00.56 Err : : 20084: 20089/0x198ede80: XXX: fstat returned with info uid=670 gid=673 mode=-rw------- size=0
08:32:00.56 Err : : 20084: 20089/0x198ede80: Log flusher encountered error 906: TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2031, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate". fslsn = 2031.0, disklsn = 2030.534409216, ckptInfo.existLFN = 2028, newestlfn = 2030.
08:32:01.56 Err : : 20084: 20089/0x198ede80: Log flusher reports success: previously-reported error 906 (TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2031, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate") no longer pending.
08:40:01.67 Err : : 20084: 20089/0x198ede80: XXX: Dbhdr group: dba Logpath:/mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2032
08:40:01.67 Err : : 20084: 20089/0x198ede80: XXX: fstat returned with info uid=670 gid=673 mode=drwxr-xr-x size=12288
08:40:01.67 Err : : 20084: 20089/0x198ede80: XXX: fstat returned with info uid=670 gid=673 mode=-rw------- size=0
08:40:01.67 Err : : 20084: 20089/0x198ede80: Log flusher encountered error 906: TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2032, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate". fslsn = 2032.0, disklsn = 2031.536557568, ckptInfo.existLFN = 2030, newestlfn = 2031.
08:40:01.67 Err : REP: 26549: UAT_DSN_DS:misc.c(247): TT16046: Failed to force log
08:40:01.67 Err : REP: 26549: UAT_DSN_DS:misc.c(247): TT722: TT0722: Log flusher reports error 906 (TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2032, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate") -- file "logflusher.c", lineno 6136, procedure "sbLogBufOSErrorPush"
08:40:01.67 Err : REP: 26549: UAT_DSN_DS:receiver.c(1241): TT16160: Failed to flush log records. Replication Agent exiting; but will be restarted by TimesTen daemon
08:40:01.75 Warn: REP: 26549: UAT_DSN_DS:receiver.c(2870): TT16060: Failed to read data from the network. TimesTen replication agent is stopping
08:40:02.68 Err : : 20084: 20089/0x198ede80: Log flusher reports success: previously-reported error 906 (TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2032, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate") no longer pending.
08:40:02.91 Err : : 20084: repagent says it has failed to start: Failed to flush log records. Replication Agent exiting; but will be restarted by TimesTen daemon
08:48:02.62 Err : : 20084: 20089/0x198ede80: XXX: Dbhdr group: dba Logpath:/mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2033
08:48:02.62 Err : : 20084: 20089/0x198ede80: XXX: fstat returned with info uid=670 gid=673 mode=drwxr-xr-x size=12288
08:48:02.62 Err : : 20084: 20089/0x198ede80: XXX: fstat returned with info uid=670 gid=673 mode=-rw------- size=0
08:48:02.62 Err : : 20084: 20089/0x198ede80: Log flusher encountered error 906: TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2033, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate". fslsn = 2033.0, disklsn = 2032.534587392, ckptInfo.existLFN = 2031, newestlfn = 2032.
08:48:02.62 Err : : 20084: 20428/0x2aac1c17e850: sbXactCommit: Unable to sync log to disk. Errors/warnings follow.
08:48:02.62 Err : : 20084: 20428/0x2aac1c17e850: TT0722: Log flusher reports error 906 (TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2033, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate") -- file "logflusher.c", lineno 6136, procedure "sbLogBufOSErrorPush"
08:48:02.62 Err : : 20084: 20428/0x2aac1c17e850: *** 20428: (Error 722): TT0722: Log flusher reports error 906 (TT0906: Cannot change mode on log file /mtsuatlog/timesten/UAT_DSN_logdir/UAT_DSN_ds.log2033, error Operation not permitted -- file "logfile.c", lineno 813, procedure "sbLogFileCreate") -- file "logflusher.c", lineno 6136, procedure "sbLogBufOSErrorPush"
08:48:02.62 Err : : 20084: 20428/0x2aac1c17e850: *** 20428: -- file "logflusher.c", lineno 6136, procedure "sbLogBufOSErrorPush"
08:48:02.63 Err : : 20084: 20428/0x2aac1c17e850: Data store marked invalid [xact.c:/st_timesten_11.2.1/3:sbXactCommit:6597] PID 20428 (timestenorad) CONN 13 (Refresher(S,60000)) Context 0x2aac1c17e850
08:48:03.57 Warn: : 20084: 2649/0x40b2590: Forced Disconnect /timesten/UAT_DSN_datastore/UAT_DSN_ds
08:48:03.57 Warn: : 20089: Stopping subdaemon HistGC thread for /timesten/UAT_DSN_datastore/UAT_DSN_ds because db is invalid.
08:48:03.57 Warn: : 20089: subd not sending crs notification, no valid socket
08:48:03.57 Warn: : 20089: Stopping subdaemon Log Marker thread for /timesten/UAT_DSN_datastore/UAT_DSN_ds because db is invalid.
08:48:03.57 Warn: : 20089: subd not sending crs notification, no valid socket
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:transmitter.c(9660): TT16127: Failed to read transaction logs
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:transmitter.c(9660): TT994: TT0994: Data store connection terminated. Please reconnect. -- file "dbAPI.c", lineno 9656, procedure "sb_dbLogReadQ"
08:48:03.57 Warn: : 20084: 2649/0x3f58850: Forced Disconnect /timesten/UAT_DSN_datastore/UAT_DSN_ds
08:48:03.57 Warn: : 20084: 2649 ----------: Disconnecting from an old instance
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:meta.c(604): TT16012: Data store is invalid. Replication Agent exiting but may be restarted by TimesTen daemon (depending on restart policy)
08:48:03.57 Warn: REP: 2649: UAT_DSN_DS:receiver.c(2870): TT16060: Failed to read data from the network. TimesTen replication agent is stopping
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:repagent.c(1237): TT16012: Data store is invalid. Replication Agent exiting but may be restarted by TimesTen daemon (depending on restart policy)
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:misc.c(247): TT16046: Failed to force log
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:repagent.c(3364): TT16005: Failed to disconnect from datastore '/timesten/UAT_DSN_datastore/UAT_DSN_ds' for 'TRANSMITTER' thread
08:48:03.57 Warn: : 20084: 20089/0x19901490: Forced Disconnect /timesten/UAT_DSN_datastore/UAT_DSN_ds
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:misc.c(247): TT994: TT0994: Data store connection terminated. Please reconnect. -- file "dbAPI.c", lineno 5166, procedure "sb_dbLogFlush"
08:48:03.57 Warn: : 20084: 20089 ----------: Disconnecting from an old instance
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:repagent.c(3364): TT846: TT0846: Data store connection invalid or not current -- file "dbAPI.c", lineno 3178, procedure "sb_dbDisconnect()"
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:repagent.c(1237): TT16012: Data store is invalid. Replication Agent exiting but may be restarted by TimesTen daemon (depending on restart policy)
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:repagent.c(3364): TT16005: Failed to disconnect from datastore '/timesten/UAT_DSN_datastore/UAT_DSN_ds' for 'LOGFORCE' thread
08:48:03.57 Err : REP: 2649: UAT_DSN_DS:repagent.c(3364): TT846: TT0846: Data store connection invalid or not current -- file "dbAPI.c", lineno 3178, procedure "sb_dbDisconnect()"
08:48:03.57 Warn: : 20084: 20089/0x19914aa0: Forced Disconnect /timesten/UAT_DSN_datastore/UAT_DSN_ds
08:48:03.57 Warn: : 20084: 20089 ----------: Disconnecting from an old instance
What I could gather from this is that Replication agent tried to change permissions of transaction logs and was unable to and the datastore was marked invalid and disconnected.
But I have not been able to find a reason for this error occurring, the environment has not been touched, there have been changes made to database objects but can they lead to this error.
If not, what is causing the error and how can we resolve it.
Thanks, your help is much appreciated.

You have a permission problem. For some reason your logfiles have the owner/group 'timesten:timesten' but based on the information from ttVersion and from the permissions on the checkpoint file they should be 'timesten:db'a. Also, the permissions shoiuld be rw-rw---- but they are set to rw-------. There could be several reasons for this, the most likely are:
1. Incorrect permissions set on the directory that holds the transaction log files.
2. TimesTen daemon processes running with incorrect userid/group.
3. Instance administrator user (timesten) no longer has group membership of the protection group (dba).
For (1), this would be 'user error'. For (2) and (3), this could only happen if permissions on TimesTen install files have been manually changed (something that should not be done without a very clear understanding of how the permissiosn need to be set) or the uid/gid for the instance administrator user has been changed at the O/S level after installing TimesTen or the 'timesten' user has been removed from the 'dba' group.
I would suggest that you check all these and see what may have been done at the O/S level.
Chris

Data Store Error Exit Code 3

Hi all,
One of the data stores that I am using constantly encounters an intermittent error which causes the data store to go down before Endeca Server restarts the data store automatically and restore access to the data store. This also causes the access to the studio page to be affected as well. I am wondering if anyone has encountered similar issues like this and perhaps has a fix for this issue? The error code that is shown on Endeca Server is as below:
"[Process watcher for 'DataStore']WARN [DGraph] 'DataStore' data store process ended with exit code 3. Automatically restarting."

Andrassy it appears that your current User account's file permissions have become compromised for the C:\Program Files (x86)\Adobe\Adobe InDesign CS5 folder. Please see Error "Exit 6" or "Exit 7" | Install log | Read, write, system file errors | CS5, CS5.5 - http://helpx.adobe.com/creative-suite/kb/error-exit-6-exit-7.html for information on how to adjust your file permissions.

Getting Error : Cannot attach data store shared-memory segment,

HI Team,
I am trying to integrate Timesten IMDB in my application.
Machine details
Windows 2003, 32 bit, 4GB RAM.
IMDB DB details
Permanent size 500MB, temp size 40MB.
If I try to connect to database using ttisql it get connected. But If I try to connect in my Java application I get following exception.
java.sql.SQLException: [TimesTen][TimesTen 11.2.1.3.0 ODBC Driver][TimesTen]TT0837: Cannot attach data store shared-memory segment, error 8 -- file "db.c", lineno 7966, procedure "sbDbCreate"
at com.timesten.jdbc.JdbcOdbc.createSQLException(JdbcOdbc.java:3269)
at com.timesten.jdbc.JdbcOdbc.standardError(JdbcOdbc.java:3418)
at com.timesten.jdbc.JdbcOdbc.standardError(JdbcOdbc.java:3383)
at com.timesten.jdbc.JdbcOdbc.SQLDriverConnect(JdbcOdbc.java:787)
at com.timesten.jdbc.JdbcOdbcConnection.connect(JdbcOdbcConnection.java:1800)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:303)
at com.timesten.jdbc.TimesTenDriver.connect(TimesTenDriver.java:159)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
Maximum permanent size that works with Java application is 100MB. But it would not be enough for our use.
Could anybody let me know the way to resolve/reason for getting this error? Any response would be appreciated.
Thanks in Advance,
Regards,
atul

This is a very common problem on 32-bit Windows. A TimesTen datastore is a single region of 'shared memory' allocated as a shared mapping from the paging file. In 'direct mode', when the application process(in your case either ttIsql or the JVM) 'connects' to the datastore the datastore memory region is mapped into the process address space. In order for this to happen it is necessary for there to be a free region in the process adddress space that is at least the size of the datastore. This region must be contiguous (i.e. a single region). Unfortunately, the process memory map in 32-bit Windows is typically highly fragmented and the more DLLs that a process uses the worse this is. Also, JVMs typically use a lot of memory, depending on configuration.
Your options to solve this are really limited to:
1. Significantly reduce the memory used by the JVM (may not be possible).
2. Use a local client/server connection from Java instead of a direct mode connection. To minismise the performance overhead make sure you use the optimised ShmIpc connectivity rather than TCP/IP. Even with this there is likely to be a >50% reduction in performance compared to direct mode.
3. Switch to 64-bit Windows, 64-bit TimesTen and 64-bit Java. Even without adding any extra memory to your machine thsi will very likely fix the problem.
Option (3) is by far the best one.
Regards,
Chris

Cannot reconnect to Timesten Data Store

Hi,
I'm using TimesTen 6.0.1 on Linux Red Hat AS 4.
My application connects well to the data store.
Then when I do:
/sbin/service tt_tt60 restart
My application is disconnected from the DS (normal), but after the data store is back, my application tries to connect again, and it does not work. I see this error log:
Sep 21 17:05:26 intel1 TimesTen Data Manager 6.0.1.tt60[11638]: ODBC_ERROR: sqldbthread 0: 3- ERROR -1 in sqlDBv2/sqldb_api.c, line 154: Error in connecting to the driver
Sep 21 17:05:26 intel1 TimesTen Data Manager 6.0.1.tt60[11638]: ODBC_ERROR: sqldbthread 0: 4- [TimesTen][TimesTen 6.0.1 ODBC Driver][TimesTen]TT0837: Cannot attach data store shared-memory segment, error 12 -- file "db.c", lineno 8623, procedure "sbDbConnect()" *** ODBC Error/Warning= 08001, Additional Error/Warning= 837
errno 12 is pointing to not enough memory
PermSize in sys.odbc.ini is 1800
If I change PermSize to 1000, it works well, the application reconnects well to the data store. But reducing PermSize would severely affect the max number of entries we can put in the database.
So, is there a way to recover from such a case without changing PermSize?
Christophe

I think we need more information to understand exactly what is happening here. Here are a few observations and suggestions:
1. When the datastore gets 'invalidated' due to the main daemon being stopped (restarted), and your application gets the error (846 or 994), what does it do? It must (a) issue a rollback on all its connections ot the DS and (b) issue a disconnect on all its connections to the DS> Until this is done, the shared memory segment for the DS will remain in existence and 'attached' to the application process. Only when the above has been done will the DS segment be released. You could use the O/S ipcs command before and after the daemon restart to see if the DS segment remains or not.
2. The O/S is denying the request to attach a new segment to the application process. The error is ENOMEM which does not necessarily mean not enough actual memory. Most likely some kernel parameter or process limit parameter is set too low such that when you trya and attach the second segment (since I suspect, as described above, that the first segment is still attached to the application) it fails. Or it may truly be that you do not have enough address space left (is this 32-bit or 64-bit) to attach the new segment.
I would recommend investigating the issues I describe in (1) above as a first step.
Chris

Cannot attach data store shared-memory segment using JDBC (TT0837)

I'm currently evaluating TimesTen during which I've encountered some problems.
All of the sudden my small Java app fails to connect to the TT data source.
Though I can still connect to the data source using ttisql.
Everything worked without problems until I started poking around in the ODBC administrator (Windows 2K).
I wanted to increase permanent data size so I changed some of the parameters.
After that my Java app fails to connect with the following message:
DriverManager.getConnection("jdbc:timesten:direct:dsn=rundata_tt60;OverWrite=0;threadsafe=1;durablecommits=0")
trying driver[className=com.timesten.jdbc.TimesTenDriver,com.timesten.jdbc.TimesTenDriver@addbf1]
SQLException: SQLState(08001) vendor code(837)
java.sql.SQLException: [TimesTen][TimesTen 6.0.4 ODBC Driver][TimesTen]TT0837: Cannot attach data store shared-memory segment, error 8 -- file "db.c", lineno 8846, procedure "sbDbConnect()"
The TT manual hasn't really provided any good explanation what the error code means.
Obviusly I'v already tried restoring the original ODBC parameters without any luck.
Ideas..anyone?
/Peter

Peter,
Not sure if you have resolved this issue or not. In any case, here are some information to look into.
- On Windows 32-bit, the allocation of shared data segment doesn't work the same way like on Unix and Linux. As a result, the maximum TimesTen database size one can allocate is much smaller on the Windows platform than on other platforms.
- Windows error 8 means ERROR_NOT_ENOUGH_MEMORY: not enough storage is available to process this command.
- TimesTen TT0837 says the system was unable to attach a shared memory segment during a data store creation or data store connection operation.
- What was the largest successful perm-size and temp-size you used when allocating the TimesTen database?
* One explanation for why you were able to connect using ttIsql is that it doesn't use much of the DLLs, whereas your Java application typically has a lot more DLLs.
* As a troubleshooting step, you can try reduce your Temp-size to a very small size and just see if you can connect to the data store. Eventually, you may need to reduce your perm-size to get Windows to fit the shared data segment in the process space.
By the way the TimesTen documentation has been modified to document this error as follows:
Unable to attach to a shared memory segment during a data store creation or data store connection operation.
You will receive this error if a process cannot attach to the shared memory segment for the data store.
On UNIX or Linux systems, the shmat call can fail due to one of:
- The application does not have access to the shared memory segment. In this case the system error code is EACCESS.
- The system cannot allocate memory to keep track of the allocation, or there is not enough data space to fit the segment. In this case the system error code is ENOMEM.
- The attach exceeds the system limit on the number of shared memory segments for the process. In this case the system error code is EMFILE.
It is possible that some UNIX or Linux systems will have additional possible causes for the error. The shmat man page lists the possibilities.
On Windows systems, the error could occur because of one of these reasons:
- Access denied
- The system has no handles available.
- The segment cannot be fit into the data section
Hope this helps.
-scheung

Cannot create data store shared-memory segment error

Hi,
Here is some background information:
[ttadmin@timesten-la-p1 ~]$ ttversion
TimesTen Release 11.2.1.3.0 (64 bit Linux/x86_64) (cmttp1:53388) 2009-08-21T05:34:23Z
Instance admin: ttadmin
Instance home directory: /u01/app/ttadmin/TimesTen/cmttp1
Group owner: ttadmin
Daemon home directory: /u01/app/ttadmin/TimesTen/cmttp1/info
PL/SQL enabled.
[ttadmin@timesten-la-p1 ~]$ uname -a
Linux timesten-la-p1 2.6.18-164.6.1.el5 #1 SMP Tue Oct 27 11:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[root@timesten-la-p1 ~]# cat /proc/sys/kernel/shmmax
68719476736
[ttadmin@timesten-la-p1 ~]$ cat /proc/meminfo
MemTotal: 148426936 kB
MemFree: 116542072 kB
Buffers: 465800 kB
Cached: 30228196 kB
SwapCached: 0 kB
Active: 5739276 kB
Inactive: 25119448 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 148426936 kB
LowFree: 116542072 kB
SwapTotal: 16777208 kB
SwapFree: 16777208 kB
Dirty: 60 kB
Writeback: 0 kB
AnonPages: 164740 kB
Mapped: 39188 kB
Slab: 970548 kB
PageTables: 10428 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 90990676 kB
Committed_AS: 615028 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 274804 kB
VmallocChunk: 34359462519 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
extract from sys.odbc.ini
[cachealone2]
Driver=/u01/app/ttadmin/TimesTen/cmttp1/lib/libtten.so
DataStore=/u02/timesten/datastore/cachealone2/cachealone2
PermSize=14336
OracleNetServiceName=ttdev
DatabaseCharacterset=WE8ISO8859P1
ConnectionCharacterSet=WE8ISO8859P1
[ttadmin@timesten-la-p1 ~]$ grep SwapTotal /proc/meminfo
SwapTotal: 16777208 kB
Though we have around 140GB memory available and 65GB on the shmmax, we are unable to increase the PermSize to any thing more than 14GB. When I changed it to PermSize=15359, I am getting following error.
[ttadmin@timesten-la-p1 ~]$ ttIsql "DSN=cachealone2"
Copyright (c) 1996-2009, Oracle. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=cachealone2";
836: Cannot create data store shared-memory segment, error 28
703: Subdaemon connect to data store failed with error TT836
The command failed.
Done.
I am not sure why this is not working, considering we have got 144GB RAM and 64GB shmmax allocated! Any help is much appreciated.
Regards,
Raj

Those parameters look ok for a 100GB shared memory segment. Also check the following:
ulimit - a mechanism to restrict the amount of system resources a process can consume. Your instance administrator user, the user who installed Oracle TimesTen needs to be allocated enough lockable memory resource to load and lock your Oracle TimesTen shared memory segment.
This is configured with the memlock entry in the OS file /etc/security/limits.conf for the instance administrator.
To view the current setting run the OS command
$ ulimit -l
and to set it to a value dynamically use
$ ulimit -l <value>.
Once changed you need to restart the TimesTen master daemon for the change to be picked up.
$ ttDaemonAdmin -restart
Beware sometimes ulimit is set in the instance administrators "~/.bashrc" or "~/.bash_profile" file which can override what's set in /etc/security/limits.conf
If this is ok then it might be related to Hugepages. If TT is configured to use Hugepages then you need enough Hugepages to accommodate the 100GB shared memory segment. TT is configured for Hugepages if the following entry is in the /u01/app/oracle/EXALYTICS_MWHOME/TimesTen/tt1122/info/ttendaemon.options file:
-linuxLargePageAlignment 2
So if configured for Hugepages please see this example of how to set an appropriate Hugepages setting:
Total the amount of memory required to accommodate your TimesTen database from /u01/app/oracle/EXALYTICS_MWHOME/TimesTen/tt1122/info/sys.odbc.ini
PermSize+TempSize+LogBufMB+64MB Overhead
For example consider a TimesTen database of size:
PermSize=250000 (unit is MB)
TempSize=100000
LogBufMB=1024
Total Memory = 250000+100000+1024+64 = 351088MB
The Hugepages pagesize on the Exalytics machine is 2048KB or 2MB. Therefore divide the total amount of memory required above in MB by the pagesize of 2MB. This is now the number of Hugepages you need to configure.
351088/2 = 175544
As user root edit the /etc/sysctl.conf file
Add/modify vm.nr_hugepages= to be the number of Hugepages calculated.
vm.nr_hugepages=175544
Add/modify vm.hugetlb_shm_group = 600
This parameter is the group id of the TimesTen instance administrator. In the Exalytics system this is oracle. Determine the group id while logged in as oracle with the following command. In this example it’s 600.
$ id
$ uid=700(oracle) gid=600(oinstall) groups=600(oinstall),601(dba),700(oracle)
As user root edit the /etc/security/limits.conf file
Add/modify the oracle memlock entries so that the fourth field equals the total amount of memory for your TimesTen database. The unit for this value is KB. For example this would be 351088*1024=359514112KB
oracle hard memlock 359514112
oracle soft memlock 359514112
THIS IS VERY IMPORTANT in order for the above changes to take effect you to either shutdown the BI software environment including TimesTen and reboot or issue the following OS command to make the changes permanent.
$ sysctl -p
Please note that dynamic setting (including using 'sysctl -p') of vm.nr_hugepages while the system is up may not give you the full number of Hugepages that you have specified. The only guaranteed way to get the full complement of Hugepages is to reboot.
Check Hugepages has been setup correctly, look for Hugepages_Total
$ cat /proc/meminfo | grep Huge
Based on the example values above you would see the following:
HugePages_Total: 175544
HugePages_Free: 175544

836: Cannot create data store shared-memory segment, error 22

Hi,
I am hoping that there is an active TimesTen user community out there who could help with this, or the TimesTen support team who hopefully monitor this forum.
I am currently evaluating TimesTen for a global investment organisation. We currently have a large Datawarehouse, where we utilise summary views and query rewrite, but have isolated some data that we would like to store in memory, and then be able to
report on it through a J2EE website.
We are evaluating TimesTen versus developing our own custom cache. Obviously, we would like to go with a packaged solution but we need to ensure that there are no limits in relation to maximum size. Looking through the documentation, it appears that the
only limit on a 64bit system is the actual physical memory on the box. Sounds good, but we want to prove it since we would like to see how the application scales when we store about 30gb (the limit on our UAT environment is 32gb). The ultimate goal is to
see if we can store about 50-60gb in memory.
Is this correct? Or are there any caveats in relation to this?
We have been able to get our Data Store store 8gb of data, but want to increase this. I am assuming that the following error message is due to us not changing the /etc/system on the box:
     836: Cannot create data store shared-memory segment, error 22
     703: Subdaemon connect to data store failed with error TT836
Can somebody from the User community, or an Oracle Times Ten support person recommend what should be changed above to fully utilise the 32gb of memory, and the 12 processors on the box.
Its quite a big deal for us to bounce the UAT unix box, so l want to be sure that l have factored in all changes that would ensure the following:
* Existing Oracle Database instances are not adversely impacted
* We are able to create a Data Store which is able fully utilise the physical memory on the box
* We don't need to change these settings for quite some time, and still be able to complete our evaluation
We are currently in discussion with our in-house Oracle team, but need to complete this process before contacting Oracle directly, but help with the above request would help speed this process up.
The current /etc/system settings are below, and l have put in the current machines settings as comments at the end of each line.
Can you please provide the recommended settings to fully utilise the existing 32gb on the box?
Machine
## I have contrasted the minimum prerequisites for TimesTen and then contrasted it with the machine's current settings:
SunOS uatmachinename 5.9 Generic_118558-11 sun4us sparc FJSV,GPUZC-M
FJSV,SPARC64-V
System Configuration: Sun Microsystems sun4us
Memory size: 32768 Megabytes
12 processors
/etc/system
set rlim_fd_max = 1080                # Not set on the machine
set rlim_fd_cur=4096               # Not set on the machine
set rlim_fd_max=4096                # Not set on the machine
set semsys:seminfo_semmni = 20           # machine has 0x42, Decimal = 66
set semsys:seminfo_semmsl = 512      # machine has 0x81, Decimal = 129
set semsys:seminfo_semmns = 10240      # machine has 0x2101, Decimal = 8449
set semsys:seminfo_semmnu = 10240      # machine has 0x2101, Decimal = 8449
set shmsys:shminfo_shmseg=12           # machine has 1024
set shmsys:shminfo_shmmax = 0x20000000     # machine has 8,589,934,590. The hexidecimal translates into 536,870,912
$ /usr/sbin/sysdef | grep -i sem
sys/sparcv9/semsys
sys/semsys
* IPC Semaphores
66 semaphore identifiers (SEMMNI)
8449 semaphores in system (SEMMNS)
8449 undo structures in system (SEMMNU)
129 max semaphores per id (SEMMSL)
100 max operations per semop call (SEMOPM)
1024 max undo entries per process (SEMUME)
32767 semaphore maximum value (SEMVMX)
16384 adjust on exit max value (SEMAEM)

Hi,
I work for Oracle in the UK and I manage the TimesTen pre-sales support team for EMEA.
Your main problem here is that the value for shmsys:shminfo_shmmax in /etc/system is currently set to 8 Gb therby limiting the maximum size of a single shared memory segment (and hence Timesten datastore) to 8 Gb. You need to increase this to a suitable value (maybe 32 Gb in your case). While you are doing that it would be advisable to increase ny of the other kernel parameters that are currently lower than recommended up to the recommended values. There is no harm in increasing them other possibly than a tiny increase in kernel resources, but with 32 GB of RAM I don't think you need be concerned about that...
You should also be sure that the system has enough swap space configured to supprt a shared memory segment of this size. I would recommend that you have at least 48 GB of swap configured.
TimesTen should detect that you have a multi-CPU machine and adjust its behaviour accordingly but if you want to be absolutely sure you can set SMPOptLevel=1 in the ODBC settings for the datastore.
If you want more direct assistance with your evaluation going forward then please let me know and I will contact you directly. Of course, you are free to continue using this forum if you would prefer.
Regards, Chris

DATA STORE IS IN FLUX BY PROCESS

Similar Messages

Maybe you are looking for