repotools.sh won't use existing content_tablespace
Hi folks, I posted on RQM forum but perhaps this belongs with JAZZ foundation.
I've built an RQM 2.0.1 on DB2 on RedHat Linux and wanted to use a "raw" device to point to an unmounted disk (character-oriented I/O. avoids the OS buffer cache).
The repotools.sh -createTables did not build, and appears to not want to use an existing file specified for the content_tablespace.
I've got to check whether "raw" character devices are still relevant to DB2 and RH LINUX, but in the "old school" using these type device files avoided filling the OS buffer cache. Since the DB2 database is ALSO building a buffer cache, it looks like a waste of RAM.
If the content_tablespace is treated as a simple file, and DB2 is populating the structure, then if that file is actually a unix "raw character" device you can do the same work.
Perhaps in the teamserver.properties file, an additional property could tell repotools to "use existing file if present". Then the tool can simply use that file. The file can then be a LINUX "raw" device pointed to the logical volume managed by the OS. It avoids using RAM to buffer, since the database will do that anyway, and leaves more RAM to support the server.
So either I should "fugged-abou-*" or repotools.sh should somehow make use of an existing file.
I've built an RQM 2.0.1 on DB2 on RedHat Linux and wanted to use a "raw" device to point to an unmounted disk (character-oriented I/O. avoids the OS buffer cache).
The repotools.sh -createTables did not build, and appears to not want to use an existing file specified for the content_tablespace.
I've got to check whether "raw" character devices are still relevant to DB2 and RH LINUX, but in the "old school" using these type device files avoided filling the OS buffer cache. Since the DB2 database is ALSO building a buffer cache, it looks like a waste of RAM.
If the content_tablespace is treated as a simple file, and DB2 is populating the structure, then if that file is actually a unix "raw character" device you can do the same work.
Perhaps in the teamserver.properties file, an additional property could tell repotools to "use existing file if present". Then the tool can simply use that file. The file can then be a LINUX "raw" device pointed to the logical volume managed by the OS. It avoids using RAM to buffer, since the database will do that anyway, and leaves more RAM to support the server.
So either I should "fugged-abou-*" or repotools.sh should somehow make use of an existing file.