Index: openacs-4/packages/acs-core-docs/www/database-management.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/database-management.html,v diff -u -r1.4 -r1.5 --- openacs-4/packages/acs-core-docs/www/database-management.html 20 Aug 2003 16:20:16 -0000 1.4 +++ openacs-4/packages/acs-core-docs/www/database-management.html 14 Oct 2003 11:02:57 -0000 1.5 @@ -1,56 +1,55 @@ - -
+
by Joel Aufrecht
OpenACS docs are written by the named authors, and may be edited
by OpenACS documentation staff.
-
To run a database on a different machine than the webserver requires changes to the database configuration file and access control file, and to the OpenACS service's configuration file.
Edit the database configuration file, which in a - Reference install is located at /usr/local/pgsql/data/postgresql.conf + Reference install is located at /usr/local/pgsql/data/postgresql.conf and change
#tcpip_socket = false
to
tcpip_socket = true
Change the access control file for the database to permit specific remote clients to access. Access can be controlled ... (add notes from forum post)
Change the OpenACS service's configuration file to point to the remote database. Edit - /web/service0/etc/config.tcl - and change
to
Skip down for instructions on Deleting a PostgreSQL tablespace. -
Skip down for instructions on Deleting a PostgreSQL tablespace. +
Should it become necessary to rebuild a tablespace from scratch, - you can use the drop user command - in SVRMGRL with the cascade + you can use the drop user command + in SVRMGRL with the cascade option. This command will drop the user and every database object the user owns.
SVRMGR> drop user service0 cascade;
- If this does not work because svrmgrl "cannot drop a user that - is currently connected", make sure to kill the AOLserver using + If this does not work because svrmgrl "cannot drop a user that + is currently connected", make sure to kill the AOLserver using this user. If it still does not work, do:
SVRMGR> select username, sid, serial# from v$session where lower(username)='service0';
and then
SVRMGR> alter system kill session 'sid,serial#';
where sid and serial# are replaced with the corresponding values for the open session.
Use with caution!
If you feel the need to delete everything related to the service, you can also issue the following:
-SVRMGR> drop tablespace service0 including contents cascade constraints;
+SVRMGR> drop tablespace service0 including contents cascade constraints;
Dropping a PostgreSQL tablespace is easy. You have to stop any AOLserver instances that are using the database that you wish to drop. If you're using daemontools, this is simple, just use the 'down' flag (-d). If you're using inittab, you have to comment out - your server in /etc/inittab, - reread the inittab with /sbin/init - q, and then restart-aolserver + your server in /etc/inittab, + reread the inittab with /sbin/init + q, and then restart-aolserver service0.
Then, to drop the db, just do:
service0:~$ dropdb service0
-DROP DATABASE
+ The "vacuum" command must be run periodically to reclaim space. The + "vacuum analyze" form additionally collects statistics on the disbursion of columns in the database, which the optimizer uses when it calculates just how to execute queries. The availability of this data can make a tremendous difference in the execution speed of queries. This command can also be run from cron, but it probably makes more sense to run this command as part of your nightly backup - procedure - if "vacuum" is going to screw up the database, you'd + procedure - if "vacuum" is going to screw up the database, you'd prefer it to happen immediately after (not before!) you've made a - backup! The "vacuum" command is very reliable, but conservatism is + backup! The "vacuum" command is very reliable, but conservatism is the key to good system management. So, if you're using the export procedure described above, you don't need to do this extra step.
Edit your crontab: