Cannot attach PL/SQL shared memory error

Hi everybody,
I got the following error when trying to reconnect the same Java process to a Timesten instance that has been restored after failure:
java.sql.SQLException: [TimesTen][TimesTen 11.2.2.6.0 ODBC Driver][TimesTen]TT8521: Cannot attach PL/SQL shared memory; virtual memory at PLSQL_MEMORY_ADDRESS already in use by TimesTen -- file "db.c", lineno 9924, procedure "sbDbConnect"
at com.timesten.jdbc.JdbcOdbc.createSQLException(JdbcOdbc.java:3238)
at com.timesten.jdbc.JdbcOdbc.standardError(JdbcOdbc.java:3387)
at com.timesten.jdbc.JdbcOdbc.standardError(JdbcOdbc.java:3352)
at com.timesten.jdbc.JdbcOdbc.SQLDriverConnect(JdbcOdbc.java:801)
at com.timesten.jdbc.JdbcOdbcConnection.connect(JdbcOdbcConnection.java:1866)
As I has understood from the Timesten Error 8521, I have to rollback and close each direct Timesten connection in my app. I implemented the solution, but it didn't help.
My app has tho copies of a database: local and remote, and two connections to these DBs: one is direct and the second is client. The last one is used as backup for the case when the direct connection is broken.
XLA is used for monitoring data changes on the local DB.
The question is: may be these XLA subscriptions prevent the shared memory segments from being released? What should I do to avoid the error 8521 during failback?

Similar Messages

When adding timesten into oem, got this Cannot attach PL/SQL shared memory;

Timesten is running on a seperate 64 bit linux server.
when adding this timesten database into oem, show this.
Warning
Failed to contact the target to be added. Following errors were received while testing the connection to the target. Update the properties accordingly, try Test Connection for testing the properties before saving.
Response - em_result=Down connect "dsn=my_ttdb;uid=oracle;pwd=***"; : Cannot attach PL/SQL shared memory; PLSQL_MEMORY_ADDRESS not valid or already in use_
the oem agent has been installed successfully and the status is running and ready.
the ttstatus showing
Data store /my_ttdb
There are 21 connections to the data store
Shared Memory KEY 0x160383c4 ID 52690968 (LOCKED)
PL/SQL Memory KEY 0x170383c4 ID 52723738 Address 0x7fa0000000
Type PID Context Connection Name ConnID
Cache Agent 6361 0x00000000180f2630 Handler 5
Cache Agent 6361 0x0000000018256dc0 Aging 6
Cache Agent 6361 0x00000000182aa410 Timer 7
Cache Agent 6361 0x0000000018337380 BMReporter(1099098432) 9
Cache Agent 6361 0x0000000018696020 Refresher(S,33000) 12
Cache Agent 6361 0x00002ab0bc1911c0 Refresher(S,31000) 10
Cache Agent 6361 0x00002ab0bc1f7db0 Refresher(S,32000) 11
Cache Agent 6361 0x00002ab0bc275d20 Refresher(S,34000) 13
Cache Agent 6361 0x00002ab0bc31f210 Refresher(S,30000) 14
Process 6321 0x000000001ed77580 my_ttdb 2
Process 6321 0x000000001ee274f0 con1 4
Subdaemon 30183 0x0000000005d1c510 Manager 2032
Subdaemon 30183 0x0000000005d71db0 Rollback 2033
Subdaemon 30183 0x0000000005e46530 Flusher 2034
Subdaemon 30183 0x0000000005e7d280 Checkpoint 2038
Subdaemon 30183 0x0000000005ed08d0 Aging 2040
Subdaemon 30183 0x0000000005f23f20 Log Marker 2041
Subdaemon 30183 0x0000000006028150 AsyncMV 2035
Subdaemon 30183 0x000000000607b7a0 Monitor 2036
Subdaemon 30183 0x000000000608edb0 HistGC 2037
Subdaemon 30183 0x00002ab0bc0008c0 Deadlock Detector 2039
Replication policy : Manual
Cache Agent policy : Manual
TimesTen's Cache agent is running for this data store
PL/SQL enabled.
Edited by: 855357 on Jun 8, 2011 7:41 AM
Edited by: 855357 on Jun 8, 2011 7:42 AM
Edited by: 855357 on Jun 8, 2011 9:21 AM

self sovled
have no idea why, just stop agent and undeploy --> deploy again
then it works

Cannot attach PL/SQL shared memory; PLSQL_MEMORY_ADDRESS not valid or

Hi
I deploy a application on weblogic(11),I configue a timesten(11.2.1.8.0) datasource named 'ttds' which used for application referenced,when i request system the error is:
<2011-10-19 下午12时05分20秒 CST> <Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "ttds": [TimesTen][TimesTen 11.2.1.8.0 ODBC Driver][TimesTen]TT8517: Cannot attach PL/SQL shared memory; PLSQL_MEMORY_ADDRESS not valid or already in use -- file "db.c", lineno 9856, procedure "sbDbConnect">
<2011-10-19 下午12时05分21秒 CST> <Error> <Deployer> <BEA-149205> <Failed to initialize the application 'ttds' due to error weblogic.application.ModuleException: .
weblogic.application.ModuleException:
     at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:302)
     at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
     at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:518)
     at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
     at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
     Truncated. see log file for complete stacktrace
Caused By: weblogic.common.ResourceException: weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: [TimesTen][TimesTen 11.2.1.8.0 ODBC Driver][TimesTen]TT8517: Cannot attach PL/SQL shared memory; PLSQL_MEMORY_ADDRESS not valid or already in use -- file "db.c", lineno 9856, procedure "sbDbConnect"
the os is xp(32bit)
datasource
url :jdbc:timesten:direct:dsn=test
driver:com.timesten.jdbc.TimesTenDriver
please help me ! thank you!

Please see this link
error:PLSQL_MEMORY_ADDRESS not valid or already in use
for comprehensive advice previously given for this error, specific to Windows 32bit.

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 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."

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

Redhat: TT0837: Cannot attach data store shared-memory segment, error 12

Customer has two systems, one Solaris and one Linux. We have six DSNs with one dsn PermSize at 1.85G. Both OS systems are 32-bit.   After migrating from TT6.0 to 11.2, I can not get replication working on the Linux system for the 1.85G dsn.   The Solaris system is working correctly.   I've been able to duplicate the issue in out lab also. If I drop the PermSize down to 1.0G, replication is started.   I've tried changing multiple parameters including setting up HugePages.
What else could I be missing? Decreasing the PermSize is not an option for this customer.   Going to a full 64-bit system is on our development roadmap but is at least a year away due to other commitments.
This is my current linux lab configuration.
ttStatus output for the failed Subscriber DSN and a working DynamicDB DSN.    As you can see, the policy is set to "Always" but it has no Subdaemon or Replication processes running.
Data store /space/Database/db/Subscriber
There are no connections to the data store
Replication policy : Always
Replication agent is running.
Cache Agent policy : Manual
Data store /space/Database/db/DynamicDB
There are 14 connections to the data store
Shared Memory KEY 0x5602000c ID 1826586625 (LARGE PAGES, LOCKED)
Type            PID     Context     Connection Name              ConnID
Replication     88135   0x56700698 LOGFORCE                          4
Replication     88135   0x56800468 REPHOLD                           3
Replication     88135   0x56900468 TRANSMITTER                       5
Replication     88135   0x56a00468 REPLISTENER                       2
Subdaemon       86329   0x08472788 Manager                        2032
Subdaemon       86329   0x084c5290 Rollback                       2033
Subdaemon       86329   0xd1900468 Deadlock Detector              2037
Subdaemon       86329   0xd1a00468 Flusher                        2036
Subdaemon       86329   0xd1b00468 HistGC                         2039
Subdaemon       86329   0xd1c00468 Log Marker                     2038
Subdaemon       86329   0xd1d00468 AsyncMV                        2041
Subdaemon       86329   0xd1e00468 Monitor                        2034
Subdaemon       86329   0xd2000468 Aging                          2040
Subdaemon       86329   0xd2200468 Checkpoint                     2035
Replication policy : Always
Replication agent is running.
Cache Agent policy : Manual
Summary of Perm and Temp Sizes of each system.
PermSize=100
TempSize=50
PermSize=100
TempSize=50
PermSize=64
TempSize=32
PermSize=1850    => Subscriber
TempSize=35     => Subscriber
PermSize=64
TempSize=32
PermSize=200
TempSize=75
[SubscriberDir]
Driver=/opt/SANTone/msc/active/TimesTen/lib/libtten.so
DataStore=/Database/db/Subscriber
AutoCreate=0
DurableCommits=0
ExclAccess=0
LockLevel=0
PermWarnThreshold=80
TempWarnThreshold=80
PermSize=1850
TempSize=35
ThreadSafe=1
WaitForConnect=1
Preallocate=1
MemoryLock=3
###MemoryLock=0
SMPOptLevel=1
Connections=64
CkptFrequency=300
DatabaseCharacterSet=TIMESTEN8
TypeMode=1
DuplicateBindMode=1
msclab3201% cat ttendaemon.options
-supportlog /var/ttLog/ttsupport.log
-maxsupportlogsize 500000000
-userlog /var/ttLog/userlog
-maxuserlogsize 100000000
-insecure-backwards-compat
-verbose
-minsubs 12
-maxsubs 60
-server 16002
-enableIPv6
-linuxLargePageAlignment 2
msclab3201# cat /proc/meminfo
MemTotal:       66002344 kB
MemFree:        40254188 kB
Buffers:          474104 kB
Cached:         19753148 kB
SwapCached:            0 kB
HugePages_Total:
2000
HugePages_Free:
2000
HugePages_Rsvd:
0
HugePages_Surp:
0
Hugepagesize:
2048 kB
## Before loading Subscriber Dsn
msclab3201# ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0xbc0101d6 1703411712 ttadmin    660        1048576    1
0x79010649 24444930   root       666        404        0
## After loading Subscriber Dsn
msclab3201# ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0xbc0101d6 1703411712 ttadmin    660        1048576    2
0x7f020012 1825964033 ttadmin    660        236978176 2
0x79010649 24444930   root       666        404        0
msclab3201#
msclab3201# sysctl -a | grep huge
vm.nr_hugepages = 2000
vm.nr_hugepages_mempolicy = 2000

The size of these databases is very close to the limit for 32-bit systems and you are almost certainly running into address space issues given that 11.2 has a slightly larger footprint than 6.0. 32-bit is really 'legacy' nowadays and you should move to a 64-bit platform as soon as you are able. That will solve your problems. I do not think there is any other solution (other than reducing the size of the database).
Chris

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

FRM-10102 Cannot Attach PL/SQL Library : Error

Hi All,
We are currently trying to upgrade from Forms6 to Forms10g.
When we open a Forms6 form in the Forms10g Developer, we are getting the error
"Cannot Attach PL/SQL Library" error.
So my question is
1. What changes do I need to make to the "FORMS90_PATH" envoirnment variable, so that it would look for the library in the current directory ?
2.Do I need to make this change in the registry or is there any other place where I can make this change ?
3. I want to make this change without hardcoding the directory name in any place. Is there any way to do it?
Thanks in advance
Aruna

Yes, I understand that I need to set the FORMS90_PATH in default.env file.
My question is how do I say "Pick up the library from the same directory as the form fmx".
Do I have to say it like
"FORMS90_PATH = C:\MyDir\Forms;" ?
I was a hesitant to hardcode the directory name( as above) in the default.env file, because incase I change the the library plx directory, I will have to update the envoirnment file again.
So is there any other way to do it ?

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

Cannot attach PL/SQL library APPCORE... forms6i

Hello,
I am trying to open the template.fmb form and I cannot seem to get forms to recognize the FORMS60_PATH variable in the registry.
I transferred (in binary) all the .pll files from $AU_TOP/resource to a local directory ORACLE_HOME\FORMS60\resource.
I transferred (in binary) TEMPLATE.fmb and APPSTAND.fmb to the same directory.
I set the HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\FORMS60_PATH to 'C:\oracle\ora806\FORMS60\resource' (without the quotes).
I added HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ORACLE_APPLICATION and set it to 'TRUE'
I added the FORMS60_PATH to the system variable file in windows to 'c:\oracle\ora806\FORMS60\resource'.
I rebooted the machine.
I am still getting the same error message.
I reinstalled forms so that it was the only Oracle product on my machine.
version (6.0.8.24.1)
I am running windows XP SP2
Can anyone tell me what I am missing? Or why I cannot get the libraries to attach?

There is a whole list of them that won't attach -
FRM-10102: Cannot attach PL/SQL library APPCORE. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library APPDAYPK. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library VERT. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library PSAC. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library CUSTOM. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library IGILUTIL. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library IGILUTIL2. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library IGI_CBC. This library attachment will be lost if the module is saved.
FRM-10102: Cannot attach PL/SQL library APPCORE. This library attachment will be lost if the module is saved.
--- all Oracle .pll files that are required to modify the template form.... APPDAYPK, APPCORE,VERT, etc. I have not tried attaching (and don't actually have) a personal library
Message was edited by:
bonnibelle

FRM-10102: Cannot attach PL/SQL Library menu_library

Dear All:
I am using Developer 6i Version 6.0.8.23.2 (32 Bit)
I am facing following error while opening a form in Forum Builder.
FRM-10102: Cannot attach PL/SQL Library menu_library. This library attachment will be lost if the module is save.
I know that I have to add the address of the folder in which the library is located, but I forgot the Registry Key value and location.
Anyone can help me?
Thanks
Hassan

Yes, I understand that I need to set the FORMS90_PATH in default.env file.
My question is how do I say "Pick up the library from the same directory as the form fmx".
Do I have to say it like
"FORMS90_PATH = C:\MyDir\Forms;" ?
I was a hesitant to hardcode the directory name( as above) in the default.env file, because incase I change the the library plx directory, I will have to update the envoirnment file again.
So is there any other way to do it ?

Cannot attach PL/SQL library APPCORE when opening template.fmb

Hi,
we have downloaded all .pll from $AU_TOP/resource directory to local folder and given path in windows registry ie HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/FORMS60_PATH to the local folder in which all pll are kept,
i have kept all the important fmb in the local folder, APPSTAND.fmb, Template.fmb and every other pll from $AU_TOP/resource, but still i get the cannot attach pl/sql library error when i open template.fmb is something missing.
Is there something missing, kindly do respond :)
thanks in anticipaition of early response.
Abdul Rahman

Hi erlative,
Thanks for your message, i just made sure that i have all the pll's only in the forms_60 path and it worked, somehow when i copied all the $AU_TOP/resource apart from APPDAYPK.pll and APPCORE, APPCORE2.pll, it didnt copy all the files, so when i copied all addittional files it worked.
thanks for your solution.
have a nice day :)
Best Regards
Abdul Rahman

Shared memory error with jcmon

When I attempt to launch jcmon.bat and access local administration, I get the following error:
ERROR => Can't attach to administration shared memory (rc=3) [jcmonxx.c 219]
Any ideas? I'm pretty sure that server0 is not running, but since I can't log into the Visual Administrator or jcmon I don't know for sure.
Thanks in advance!

Hi all,
jcmon.exe pf=I:usrsapVIKSYSprofileVIK_DVEBMGS00_VIKLAB
You will find the below, see the server0 is stopped. Thats what is not starting in our case, and that is the j2ee engine I suppose. Because the dispatcher and the SDM starts as can be seen. If you attempt to restart the process from the jcom administration menu, it wont because if it did then we would not have this problem in the first place. The sapinst tool is calling this.
============================================================
JControl Monitor Program - Main Menue
============================================================
0 : exit
10 : Cluster Administration Menue
20 : Local Administration Menue
command =>
SAP System Name : VIK
SAP System : 00
MS Host : VIKLAB
MS Port : 3601
Process Count : 3
PID of JControl : 1116
State of JControl : Some processes running
State inside MS : Some processes running
Run Mode : Normal Mode
Admin URL :
Idx
Name
PID
State
Error
Restart
0
dispatcher
3948
Running
0
yes
1
server0
0
Stopped
4
no
2
SDM
4564
Running
0
yes
I think the problem here seems to be the wrong JDK version.
Take this very seriously. I think this might save days of trouble,
SAP faces installation problem if you have an SDK/JDK lesser than 1.4.2_11. I did not take this very seriously and have 1.4.2_10 but then this thread below clearly says that there are problem with installations when you use 1.4.2_10. Useful for guys stuck in the same hole. This might be the reason why the java server process does not start while the java dispatcher and SDM starts.
The link for this JDk recommendation thread is
8) SAP J2EE-DEP 6.40 certification - JDK requirements
"SAP J2EE-DEP 6.40 certification - JDK requirements "
==>
So please adhere to the following:
Linux 32 Bit + 64 Bit (Itanium)
Windows 32 Bit + 64 Bit (Itanium)
Access to appropriate Sun J2SE Version:
Please use Sun J2SE 1.4.2_09 SDK (or higher 1.4.2 versions after they will become available).
It is not recommended to use versions lower than 1.4.2_09.
Please also do not use J2SE 5.0.
In contrast to the recommendation above please do not use J2SE 1.4.2_10 as it has problems during installation. The problem is under investigation.
The J2SE 1.4.2 SDK is available from
http://java.sun.com .
regards, Vikram

Shared memory error

Hi Gururs,
while end user opening query getting error.
But when iam opening same query it is working successfully.
He is facing shared memory error.
What is the problem?How to slove the problem?
Thanks in advance
Ram

Hi Ramu,
OSS note:543482 talks abt memory issues, may not be very relevant in your case but still you can have a look at it.
Also, try to work with your DBA to increase the memory and check for the Global Cache set up for the system. If it is less than increase the size of Global Cache..
Cheers!
Amit

Cannot attach PL/SQL shared memory error

Similar Messages

Maybe you are looking for