Changes between Version 8 and Version 9 of OracleTestSetup

Timestamp:

Nov 14, 2010, 7:16:31 AM (14 years ago)

Author:

Ramiro Morales

Comment:

--

OracleTestSetup

@@ -10 +10 @@
 suite against Oracle by:
 
-  * Providing a step by step setup guide to achieve that.
-  * Hopefully collecting information (best practices, tuning tips) to do that
-    as efficiently as possible.
+* Providing a step by step setup guide to achieve that.
+* Hopefully collecting information (best practices, tuning tips) to do that
+  as efficiently as possible.
 
 Chosen components are:
@@ -134 +134 @@
    ``sudo service xe start``)
 
-#. Make sure the Oracle environment vars needed by its client libraries
-   are set (Bash shell)::
+
+#. Make sure the Oracle environment vars needed by its client libraries are set. You need to do this in all systems
+   where you will be running client apps (e.g. the django test runner, the Oracle ''sqlplus'' CLI admin tool, etc.):
+   the system where the DB engine will run and/or other systems connected to it through the network (see next item).
+
+   I use the Bash shell, see the Oracle docs for instructions for other shells::
 
     $ echo "source /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh" >> ~/.bashrc
     $ source /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle_env.sh
-
 
 #. Decide if you will perform the following two tasks
@@ -154 +157 @@
    * By default no access of any type (SQL sessions, admin web app) is allowed through the network to the DB engine, you need to change that by using the administrative web interface or possibly using the `sqlplus` tool.
 
-#. Access the DB engine administration web app by pointing our Web browser to ``http://localhost:8080/apex`` (or ``http://server:8080/apex``)
+#. Access the DB engine administration web app by pointing your Web browser to ``http://localhost:8080/apex`` (or ``http://server:8080/apex``)
    and using the ``SYSTEM`` user plus the password you chose above.
 
@@ -244 +247 @@
 
 In my particular case I've implemented this setup by using a KVM virtual machine 
-(host system is a workstation running Debian unstable *Sid*). The VM got two CPUs, 1 GiB of RAM
-and a 30 GiB hard disk. Platform is GNU/Debian Linux 5.0 aka *Lenny* (stable as of Nov 2010)
-because it still is in its support period and as a bonus contains Python 2.4 in pre-packaged
-form.
+(host system is a workstation running Debian unstable *Sid*). The VM got:
+
+* one CPU (Oralce XE won't use any additional CPU).
+* 512 MiB of RAM (initially it was 1GiB but the Django test suite execution doesn't push memory usage above that at all).
+* 30 GiB hard disk.
+
+Platform is GNU/Debian Linux 5.0 aka *Lenny* (stable as of Nov 2010) because it still is in
+its support period and as a bonus contains Python 2.4 in pre-packaged form.
 
 Things to review:
 
 * How much does the Oracle installation pollutes the system?. If it result to be confined and easy to undo/cleanup, maybe this setup doesn't need to be done inside a VM.
-* System resource (CPU, RAM usage while running the full test suite). Maybe I can reduce the RAM assigned to the VM to 512 MiB and the virtual CPU count from two to one.
 }}}