TimesTen

Oracle TimesTen 内存数据库

第一章Timesten

1.1 TT的简介

1.2 TT的特性

1.3 TT的基本概念

1.4 DataStore介绍

1.5 用户级别

1.6 锁机制

1.7 数据持久性

1.8 索引

1.9 命令大全

1.10 DSN属性大全

1.11 环境变量

第二章LINUX平台下

2.1 安装

2.2 启动和关闭

2.3 创建数据源

2.4 C/S配置

2.5 CacheConnect

2.6 复制配置

2.7 复制异常恢复

第三章WINDOWS平台下

3.1 安装

3.2 创建数据源

3.3 初步使用

3.4 C/S配置

3.5 CacheConnect

第一章Timesten

1.1 TT的简介

Oracle TimesTen 内存数据管理软件由TimesTen数据库服务器、数据复制选件和高速缓存选件三部分组成。本文该部分简要介绍了这些产品和技术，后续部分将提供更多详细信息。

?Oracle TimesTen In- Memory Database

Oracle TimesTen In-Memory Database 是一个内存优化的关系数据库，

它为应用程序提供了当今实时企业和行业（例如电信、资本市场和国防）所需的即时响应性和非常高的吞吐量。Oracle TimesTen In-Memory

Database 作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用

标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。

?Replication – TimesTen to TimesTen

Replication – TimesTen to TimesTen 是 Oracle TimesTen In-Memory Database 的一个选项，它支持服务器间的实时数据复制，以获得高可用

性和负载共享。数据复制配置可以是双机热备份 (active-standby) 或负载均衡 (active-active)，可以使用异步或同步传输，可以包含冲突检测

和冲突解决以及在故障服务器恢复后自动重新同步。数据复制与 Cache

Connect to Oracle 选项完全兼容。

?Cache Connect to Oracle

Cache Connect to Oracle 是 Oracle TimesTen In- Memory Database 的一个选项，它为位于应用程序层中的 Oracle 数据创建实时、可更新的高速缓存。它免除了后端系统的计算负担，并支持反应灵敏且可伸缩的实时

应用程序。Cache Connect to Oracle 能够将 Oracle 数据的子集加载到TimesTen 中，能够双向传播更新，能够使对非高速缓存数据的 SQL 请求的透传自动化，并能够在故障之后自动重新同步数据。Cache Connect to Oracle 与 Replication – TimesTen to TimesTen 选项完全兼容。

1.2 TT的特性

TimesTen的名字就是 Ten Times，意思就是比传统的数据库要快一个数量级，为什么同是数据库，TimesTen要快这么多？如果把传统的数据库中的数据全部先load到内存中是否能达到相同的效果？下面我们对它们做一个比较分析。

?第一，传统的数据库和应用程序是两个不同的应用系统，它们之间的通讯是通过IPC连接来实现的。而TimesTen则是直接把数据库的内存映射到

应用程序的地址空间中，简单来说，这时候TimesTen访问数据库中的数

据，就象访问应用程序自己的数组、字符串变量一样，只不过TimesTen

有一套完善的机制来实现数据的一致性和完整性。这种直接嵌入到应用程序的运行地址空间机制比IPC要高效很多。

?第二，传统的数据库都是 Disk-based 的，即预先假定数据主要是放在磁盘中的，所以它的所有优化、查询算法都是以磁盘存储为主的。举个简单的例子，比如说要查找一行记录，传统的数据库要先查找索引，通过索引查找该记录所在的页面，然后通过查找该页是已经在内存中，还是要从磁盘的数据文件中读取出来。而TimesTen是预先就把所有的数据Load到内存中，它知道所有的数据一定在内存里面，不会再通过其它的调用去决定数据在哪儿，这其中就少走了很多的弯路，基本没有磁盘的IO，而且都

在内存中，效率也就高了很多。所以即使传统的数据库把数据都预先Load 的内存中，也是达不到TimesTen的效果的。因为传统数据库的索引机制、优化算法、复杂的数据结构、数据的获取机制等等因素限制了它的性能。

?第三，由于TimesTen启动的时候预先将所有的数据 Load 到内存中，所以它没有页进页出，而且也不需要类似与Oracle中的SGA缓冲区的管理。

总之，TimesTen只用 1/10 的CPU指令完成了传统数据库同样的任务，从而使得性能和吞吐量提升了一个数量级。

下图说明了其中的不同之处:

1.3 TT的基本概念

TimesTen作为一个可以单独使用的标准关系型数据库而言，它也有自己的实例、库、日志等概念的。只是术语上和Oracle有些不同，但内在的含义是类似的。

?实例

实例也就是Instance，对TimesTen来说，一个安装对应一个实例，如果你在同一台机子上，用不同的用户安装了多个TimesTen，那么就可以说，你在这台机子上有多个实例。

?库

在TimesTen中和Oracle库对应的概念是DataStore，它通过DSN 定义。安装TimesTen之后，在sys.odbc.ini配置文件中有多个DataStore的定义，每个DataStore就是一个库。所以一个实例可以对应多个库，但一个库只能属于一个实例。

?日志

TimesTen也有自己的日志文件，以及存放日志文件的目录（LogDir），缺省的就是和DataStore放在同一个目录下。但一般建议分开放。日志的概念和Oracle的一样，在回滚以及恢复的时候，都会用到它。

?数据文件

也可以叫检查点（checkpoint）文件，Oracle中比较接近的就是dbf 文件了。它是TimesTen当前内存中数据的一个镜像，恢复的时候先找到最近的检查点文件，然后结合日志文件一起恢复。TimesTen 写检查点文件是增量写的方式，不是整个数据都写的。所以性能上还是很好的。

1.4 DataStore介绍

DataStore 是指TimesTen中的表、索引等放在内存段中的一个集合，类似与Oracle中库的概念。一个TimesTen Data Manager可以管理多个DataStore。DataStore由放在相应ODBC配置文件中的一个DSN（Data Source Name）所定义，该DSN由一个名字和相关的属性组成，如下：

[dsa]

Driver=/home/tt1/TimesTen/tt70/lib/libtten.so

DataStore=/home/tt1/TimesTen/tt70/info/dsa

DatabaseCharacterSet=ZHS16GBK

PermSize=50

TempSize=10

上面是名为test的DataStore的定义，ODBC配置文件分为两种：系统级ODBC文件(可通过环境变量SYSODBCINI另行设置)和用户级ODBC配置文件（可通过环境变量ODBCINI另行设置）。系统级的ODBC可以被任何用户所引用，而用户级的只能被该用户所引用。系统级的ODBC文件在Windows平台下可以通过控制面板→ ODBC数据源管理→系统DSN 定义；而UNIX平台下，则一般是通过定义文件$INSTALL_DIR/sys.odbc.ini完成。

当用户连接一个DataStore的时候，TimesTen会按照下面的顺序查找配置文件：

1. 环境变量ODBCINI所指向的.odbc.ini文件

2. 运行TimesTen的用户主目录下的.odbc.ini 文件

3. 环境变量SYSODBCINI所指向的sys.odbc.ini文件

4. /var/TimesTen/sys.odbc.ini

5. $INSTALL_DIR /info/sys.odbc.ini（非root用户才会执行该步）

一般情况下，建议使用非root用户安装，原因是便于管理而且对系统的安全没有影响。此时，ODBC配置文件缺省位于$INSTALL_DIR /info/sys.odbc.ini ，$INSTALL_DIR为TimesTen的安装目录。

在上面的test 定义里面，有两个重要的属性：

Driver=/home/tt1/TimesTen/tt70/lib/libtten.so

DataStore=/home/tt1/TimesTen/tt70/info/dsa

Driver比较好理解，是指操作该数据源所需要的驱动。而DataStore指的是

放置Checkpoint文件的磁盘地址。TimesTen虽然运行的时候将所有的数据都预

先装载在内存中，但不是说它就不需要任何磁盘文件，它也有自己的数据文件、日志文件等。这个数据文件叫checkpoint 文件，是TimesTen内存中数据在磁盘上的一个镜像，相当于Oracle数据库中的数据文件DBF。TimesTen会在一定条件下自动做Check point ，此时，它会将内存中的脏数据和磁盘上的数据文件做增量同步。当首次登陆到该DSN，或者TimesTen异常中止/失败时，TimesTen

需要这些读取这些文件做恢复。

下面是DataStore dsa 在磁盘上的相应文件：

[tt1@west-mountain info]$ pwd

/home/tt1/TimesTen/tt70/info

[tt1@west-mountain info]$ ls -al|grep dsa

-rw-rw-rw- 1 tt1 tta 11446924 Jun 17 21:28 dsa.ds0

-rw-rw-rw- 1 tt1 tta 11446924 Jun 17 21:22 dsa.ds1

-rw-rw-rw- 1 tt1 tta 557056 Jun 17 21:28 dsa.log0

-rw-rw-rw- 1 tt1 tta 67108864 Jun 17 21:12 dsa.res0

-rw-rw-rw- 1 tt1 tta 67108864 Jun 17 21:12 dsa.res1

-rw-rw-rw- 1 tt1 tta 67108864 Jun 17 21:12 dsa.res2

针对dsa这个DataStore，磁盘上对应由两个checkpoint 文件，dsa.ds0，dsa.ds1；一个日志文件，dsa.log0；以及三个保留文件(reservation) dsa.res0，dsa.res1，dsa.res2。在ODBC的配置文件中，我们只是定义了dsa的DataStore属性：

DataStore=/home/tt1/TimesTen/tt70/info/dsa

这个属性看起来只是定义了一个目录路径，TimesTen是如何根据该属性创建一系列文件且命名的呢？针对Checkpoint文件，TimesTen会以DataStore属性的

最后一节为文件名，创建相应的Checkpoint文件。所以我们看到了在目录

/home/tt7/TimesTen/tt70/info 下有两个分别命名为dsa.ds0，dsa.ds1的文件。TimesTen每次做Checkpoint的时候，会轮换着写这两个文件，每次都写较旧的那个。所以在某些时间段内，这两个文件不是完全一致的。每次做Checkpoint

的时候，TimesTen先在这两个文件之间做一个同步，然后把最新的更新，写到旧的Checkpoint文件中。为什么不同时写入两个文件呢？原因是如果同时往两个文件写入，而写入过程发生异常，会导致两个文件同时被损坏，带来灾难性的后果。

那么TimesTen如何创建日志文件（dsa.log0）和保留文件(dsa.res0~3)呢？可以在ODBC配置文件里面，通过属性LogDir 来定义日志文件。因为日志文件会和保留文件始终位于同一个目录下，所以LogDir也间接地定义了保留文件。当没有显式设置LogDir时，日志文件将和Checkpoint文件位于同一目录下，且以DataStore属性中定义的目录的最后一节为文件名，且后缀中按数字序列递增命名，例如dsa.log0，dsa.log1，dsa.log2。。。等。当具体定义了LogDir后，日志文件将位于该目录下，且以该属性值所指向的目录的最后一节为文件名，例如：LogDir=/home/tt1/TimesTen/tt70/testcache

此时，TimesTen将在目录/home/tt1/TimesTen/tt70/testcache 下创建名为testcache的日志和保留文件。

[tt1@west-mountain testcache]$ pwd

/home/tt1/TimesTen/tt70/testcache

[tt1@west-mountain testcache]$ ls -al

total 25016

drwxr-xr-x 2 tt1 tta 4096 Dec 28 10:50 .

drwxr-xr-x 13 tt1 tta 4096 Dec 28 10:53 ..

-rw-rw-rw- 1 tt1 tta 376832 Dec 28 14:12 testcache.log0

-rw-rw-rw- 1 tt1 tta 67108864 Dec 28 10:50 testcache.res0

-rw-rw-rw- 1 tt1 tta 67108864 Dec 28 10:50 testcache.res1

-rw-rw-rw- 1 tt1 tta 67108864 Dec 28 10:50 testcache.res2

强烈建议将日志文件和Checkpoint文件分开放在不同磁盘上，且处于不同的磁盘控制器下，以尽量减少磁盘IO的影响。可能的话，正式的生产系统中，这两个目录一般都配置在已经条带化之后的磁盘阵列上不同的逻辑盘中。

下面讲讲保留文件（dsa.res0，dsa.res1，dsa.ds2）

[tt1@west-mountain info]$ ls -al|grep dsa

-rw-rw-rw- 1 tt1 tta 11446924 Jun 17 21:28 dsa.ds0

-rw-rw-rw- 1 tt1 tta 11446924 Jun 17 21:22 dsa.ds1

-rw-rw-rw- 1 tt1 tta 557056 Jun 17 21:28 dsa.log0

-rw-rw-rw- 1 tt1 tta 67108864 Jun 17 21:12 dsa.res0

-rw-rw-rw- 1 tt1 tta 67108864 Jun 17 21:12 dsa.res1

-rw-rw-rw- 1 tt1 tta 67108864 Jun 17 21:12 dsa.res2

保留文件始终和日志文件位于同一目录下，它的大小由属性LogFileSize定义。缺省的LogFileSize是64M，所以缺省的保留文件就是67108864字节。

当由于某些原因导致文件系统没有空余的磁盘空间时，如果没有保留文件，TimesTen将无法运行下去，因为事务的提交不可避免地导致日志文件的增长，但此时已没有任何可用于增长的磁盘空间，从而导致TimesTen处于静止（Quiescent）状态，在此状态下，只允许读操作而不允许写操作。保留文件是作为溢出缓冲空间使用的，它们被预先创建，当磁盘空间都被用光时，TimesTen会利用这些保留文件作为一个缓冲，从而完成最终的一些事务，避免TimesTen进入静止状态。而创建三个保留文件的原因是因为在绝大多数情况下，三个保留文件被证明是最优的选择。当然，不管如何，磁盘空间被用光的情况都应该尽量地避免。

1.5 用户级别

当安装TimesTen的时候，安装用户即是TimesTen的DBA，这一点和Oracle是类似的。这个用户也叫外部用户，因为它是操作系统的用户。安装的时候如果选择 access control 为 enable ，那么就能在登录TimesTen之后，创建TimesTen 的用户了，这时候创建的用户称为内部用户。

在TimesTen的配置文件 sys.odbc.ini 中，有一些缺省的DSN定义，大部分都是为 Demo 服务的。但有一个比较特别，就是第一个，它的名字一般是前缀 TT_ ，然后加上你安装时候的确定的 Instance 名字，比如我们选择的Instance名字为 tt705，那么它的全名就是 TT_tt705。这个DSN是比较特别的一个，看起来

好像和其它没什么区别，也能访问。但在以前的一些版本中有些操作是不能在这个DSN上做的。所以个人觉得创建自己的DSN的时候，最好不要碰这个DSN，还是以这个为模板，另创建一个的好。

当创建TimesTen的内部用户的时候，创建的用户都是 Instance 级的。比如，我们创建了一个DSN 叫 tt_test。这时候我们登录到 TT_tt705，创建一个用户叫 tt，并赋予相关权限后，那么用这个 tt 用户就可以登录到该Instance下的所有DSN了，包括 tt_test。至少到TimesTen 7.0.5为止还是这样的。

[tt705@west-mountain info]$ ttisql "dsn=tt_test;uid=tt"

Copyright (c) 1996-2008, Oracle. All rights reserved.

Type ? or "help" for help, type "exit" to quit ttIsql.

All commands must end with a semicolon character.

connect "dsn=tt_test;uid=tt";

7001: User authentication failed

The command failed.

Done.

[tt705@west-mountain info]$ ttisql tt_tt705

Copyright (c) 1996-2008, Oracle. All rights reserved.

Type ? or "help" for help, type "exit" to quit ttIsql.

All commands must end with a semicolon character.

connect "DSN=tt_tt705";

Connection successful: DSN=TT_tt705;UID=tt705;DataStore=……

(Default setting AutoCommit=1)

Command> create user tt identified by ‘tt’;

Command> grant all to tt;

Command> exit

Disconnecting…

Done.

[tt705@west-mountain info]$ ttisql "dsn=tt_test;uid=tt;pwd=tt" Copyright (c) 1996-2008, Oracle. All rights reserved.

Type ? or "help" for help, type "exit" to quit ttIsql.

All commands must end with a semicolon character.

connect "dsn=tt_test;uid=tt";

Connection su ccessful: DSN=tt_test;UID=tt;DataStore=……

(Default setting AutoCommit=1)

Command> call ttusers;

< TT705 , 1, FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF >

< SYS , 0, 00000000000000000000000000000000 >

< TTREP , 0, 00000000000000000000000000000000 >

< PUBLIC , 0, 03000000000000000000000000000000 >

< TT , 0, FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF >

< TEST , 0, FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF >

6 rows found.

Command> exit

Disconnecting…

Done.

1.6 锁机制

锁是一种较高级的处理并发性访问的机制，它序列化多个应用对资源的同时访问。当一个用户正在读取或者修改该资源时，阻止其它用户对该资源的修改。TimesTen有三种锁机制：

?DataStore级锁

?表级锁

?行级锁

可以在ODBCINI配置文件中通过参数LockLevel设置是DataStore级锁还是行级锁，也可通过存储过程ttLockLevel() 动态设置。应用程序可以调用存储过程ttOptSetFlag() 提示查询优化器采用行级锁（RowLock）还是表级锁（TblLock）。还可通过存储过程ttLockWait() 设置等待锁的时间。

?DataStore级锁

当一个进程访问DataStore时，如果该DataStore为DataStore级锁，则其它进程不能同时访问该DataStore，即DataStore级的锁都是排他的。只有在当前DataStore上没有活动的事务时，才能获取DataStore级的锁。一旦获得DataStore级锁，其它事务将被阻塞直到该锁定被释放。

DataStore级锁限制了应用的并发性访问，只有在有限的场景下才使用该锁定，如初始化、数据批量导入等。由于DataStore级锁比行级锁和表级锁反应时间更快，所以在适合它的使用场景下能取得更好的性能。

?表级锁

当事务要对一个表的大部分记录进行查询、修改或者删除时，就会获得表级锁。查询优化器会根据具体的SQL来判断是否应该使用表级锁，该过程对应用来说是透明的。当然也可通过存储过程ttOptSetFlag() 来手工动态设置。

因为表级锁也会降低应用的并发性，所以只有当一个表的大部分行需要被锁定，或并发性要求不高时才会采用表级锁。

?行级锁

相对DataStore级锁和表级锁，行级锁的并发性是最好的。它只锁定要操作的行，所以不同的应用可以同时操作同一个表中不同的行。

1.7 数据持久性

TimesTen作为一个内存数据库，数据完全放置在内存中，那么它的数据持久性如何保持？以及如何实现高可用性保证的呢？

TimesTen的数据持久性是通过磁盘上的DataStore文件和Log文件保持的。TimesTen每一次操作，都会先缓存在内存的LogBuffer中，然后由后台的守护进程异步地同步到磁盘上的Log文件中。TimesTen 每隔一段时间或者收集到一定的脏日志量后，就触发一次Checkpoint，将内存中变化的数据增量写到磁盘上的DataStore文件中，然后清除掉已经同步过的Log文件。所以当掉电，或者其它故障时，TimesTen可以通过这些文件进行自动恢复。

至于高可用性保证，如果是单节点，不想有任何的数据丢失，TimesTen可以通过设置参数DurableCommits =1来保证，即每次提交都强制性同步到磁盘上（缺省为异步方式），这种情况下，数据库写的性能会受到影响。所以如果既想保持高性能，又能保证数据的高可用性，TimesTen通过Replication 机制完美地达到了上述两点，通过Replication，TimesTen在多个节点的之间保持数据的自动高效同步。节点之间由多种复制模式可以选择：Active-Standby，Active－Active，Active－Standby－Disaster Recovery等等；数据的传送模式也有同步、半同步、完全同步等三种模式。

1.8 索引

1) TimesTen索引目前分两种：

Hash索引做等值匹配查询具有较大的优势，但占用空间较大；只能出现在primary key上。

T-tree索引则适宜做范围、排序等查询（Order By,Group By,Distinct），当然它也可做等值查询，占用空间较小。语法create index test_idx on test(a,b);

2) 主键缺省具有Hash索引。

3) 建Hash 索引时必须定义Pages值（Rows/256）,以避免Hash冲突。

4) 全表扫描时候，如果被扫描的表具有T-tree索引（不管这个索引的列是否被用到），则性能会有较大的

提升。

5) 组合索引时，Hash 索引需要列的完全匹配，而T-tree索引只需要前置匹配。如：

SELECT … FROM T1 WHERE COL1 = ? AND COL2 = ?

6) 对下列语句

WHERE c1+10 < c2+20写成WHERE c1 < c2+10在C1上创建索引

7) 如果表的空间无法预测，即不能定义Pages的值，或者索引的列中包含大的Char/Binary 以及组合列时，

建议使用unique index

用如下两个存储过程进行表的分析，以提高执行的效率

ttOptUpdateStats （全表）

ttOptEstimateStats （抽取部分）

9) 执行计划会一直使用，直到碰到下列情形：

A table it uses is dropped

A table it uses is altered

An index on a table it references is dropped

An index is created on a table it references

Statistics are recomputed

10) 执行计划：

Command> autocommit 0;

Command> showplan 1;

Command> prepare SELECT * from test;

或：

Command> autocommit 0;

Command> call ttOptSetFlag(’GenPlan’,1);

Command> prepare SELECT * from test;

Command> SELECT * FROM plan;

11) 有时候系统也会创建临时索引以加快查询速度，但如果临时索引创建地过于频繁，就要考虑手工建相

应的索引，这可以通过系统表MONITOR 的列CMD_TEMP_INDEXES来监测。

1.9 命令大全

Command>

1.11 环境变量

下列为TimesTen安装之后，可能需要设置的系统变量：

◆CLASSPATH

如用到JDK，则需要设置该变量指向相应的Jar文件。目前支持的JDK有JDK1.4、JDK5.0、BEA Weblogic Jrockit 5.0

◆LIB、LIBPATH、LD_LIBRARY_PATH、SHLIB_PATH

指向TimesTen所用到的共享库，即$INSTALL_DIR/LIB 目录；如用到Cache Group，还需包含$ORACLE_HOME/LIB 或$ORACLE_HOME/LIB （32位平台）。

且不同的平台该变量的名字各有差异：

SOLARIS — LD_LIBRARY_PATH

AIX — LIBPATH

HP-UX 32Bit — SHLIB_PATH

HP-UX 64Bit — LD_LIBRARY_PATH （$INSTALL_DIR/LIB）

—SHLIB_PATH （$ORACLE_HOME/LIB）

Tru64 UNIX — LD_LIBRARY_PATH

注意：HP-UX 64Bit平台需要两个系统变量分别指向TimesTen和Oracle 的相应LIB目录。

◆ODBCINI

指向.odbc.ini 配置文件。当用户连接TimesTen的时候，TimesTen会按照下面的顺序查找相关的配置文件：

1.环境变量ODBCINI所指向的.odbc.ini文件

2.运行TimesTen的用户主目录下的.odbc.ini 文件

3.环境变量SYSODBCINI所指向的sys.odbc.ini文件

4./var/TimesTen/sys.odbc.ini

5.install_dir/info/sys.odbc.ini（非root用户才会执行该步）

◆ORACLE_HOME

指向Oracle 数据库的安装目录，如果要用到Cache Group，该变量必须设置。

◆PATH

指向TimesTen的bin 目录，即$INSTALL_DIR/bin；如果用到Cache Group的话，还要包含Oracle的bin目录。

◆SYSODBCINI

指向SYS.ODBC.INI配置文件，具体说明见ODBCINI

◆SYSTTCONNECTINI

当用Client/Server 模式访问TimesTen的时候，该变量指向客户端的sys.ttconnect.ini配置文件。客户端查找配置文件的顺序是：

1. 环境变量SYSTTCONNECTINI所指向的sys.ttconnect.ini 配置文件。

2. /var/TimesTen/sys.ttconnect.ini

3. $INSTALL_DIR/info/sys.ttconnect.ini（非root用户安装）

◆TMP/TMPDIR

指向TimesTen的临时目录。TimesTen的某些操作，比如ttRepAdmin –duplicate 、大的删除等会用到临时目录。该参数缺省设置为：HP-UX 和AIX 是/var/tmp；而Solaris、Linux、Tru64 UNIX 则是/tmp。

第二章LINUX平台下

2.1 安装

安装前检查

/*确定Linux的版本及内核*/

[root@west-mountain ~]# cat /etc/redhat-release

Red Hat Enterprise Linux AS release 4 (Nahant Update 4)

[root@west-mountain ~]# uname -a

Linux west-mountain 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux

/*确定Linux平台的位数*/

[root@west-mountain ~]# getconf WORD_BIT

32

/*确定空闲内存及硬盘大小*/

[root@west-mountain ~]$ free

[root@west-mountain ~]# free -k

total used free shared buffers cached

Mem: 1010220 779232 230988 0 83976 567584

-/+ buffers/cache: 127672 882548

Swap: 1052248 0 1052248

[root@west-mountain ~]$ df -k

[root@west-mountain ~]# df -k

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/sda3 11242612 6481940 4189564 61% /

/dev/sda1 101086 11427 84440 12% /boot

none 505108 0 505108 0% /dev/shm

[root@west-mountain ~]# ipcs -l

—— Shared Memory Limits ——–

max number of segments = 4096 // SHMMNI

max seg size (kbytes) = 1048576 // SHMMAX

max total shared memory (kbytes) = 8388608 // SHMALL

min seg size (bytes) = 1

—— Semaphore Limits ——–

max number of arrays = 128 // SEMMNI

max semaphores per array = 250 // SEMMSL

max semaphores system wide = 32000 // SEMMNS

max ops per semop call = 100 // SEMOPM

semaphore max value = 32767

—— Messages: Limits ——–

max queues system wide = 16 // MSGMNI

max size of message (bytes) = 8192 // MSGMAX

default max size of queue (bytes) = 16384 // MSGMNB

/*针对TimesTen来说，SHMMAX 和SHMALL 是两个非常重要的内核参数参数，一般都需要重新设定其值。SHMMAX 是Linux 系统上共享内存段的最大大小。SHMALL 是系统上可分配的共享内存页的最大大小。缺省情况下，SHMALL 设置为8 GB（8388608 KB = 8 GB）。安装TimesTen之前，我们需要将上述两个参数设置为不低于实际的物理内存的大小。如系统的实际物理大小为4G，则需要设置SHMMAX为1024*1024*4 = 4194304; 而由于SHMALL 缺省为8G，可以不用修改。但如果系统的实际物理内存超过8G ，则须修改SHMALL的值为实际的大小。内核参数信号量由以下四个标记组成：SEMMSL、SEMMNS、SEMOPM 和SEMMNI。

● SEMMSL每个数组的最多信号量个数

● SEMMNS系统范围内最多允许的信号量个数

● SEMOPM每次semop 调用的最大操作数

● SEMMNI最多允许的数组个数

在TimesTen中，一般在文件/etc/sysctl.conf 文件中加入下行设置，且重启服务器使之生效kernel.sem = “250 32000 100 100″ 上行kernel.sem设置了如下的四个值：

SEMMSL=250

SEMMNS=32000

SEMOPM=100

SEMMNI=100

IPCS – l 命令返回的Message部分说明了系统上的消息：MSGMNI 将影响可以启动的代理进程数，MSGMAX 将影响一个队列中可以发送的消息大小，而MSGMNB 将影响队列大小。TimesTen对这一块倒是没有特别的要求，但一般来说，在服务器系统上，将MSGMAX 一般设置为64 KB（即，65535 个字节），MSGMNB 设置为65535。/*另外也可以通过下列命令来检查或修改相应的内核参数，以下操作需要root权限，检查shmmax值*/

[root@west-mountain root]# /sbin/sysctl -a |grep shmmax