Hi,
I am new to this database product (normally MSSQL) and currently doing
a 15gb database migration to a new server. The new server has the
following specs:
2 x 3.6 Xeon
4gb Ram
2 x 36gb Mirrors (1 for System and 1 for Logs)
HDS 2tb SAN with 2gb Cache
However after starting the install with the framework vendor I have
been told that PerSQL doesn't use logs and backups come just from
straight file copys. Is this correct? I have been looking through the
settings and transactional logging in enabaled and set to the same
drive as the system files. Are these the same sort of logs used in
MSSQL? Also performance is the key reason for this upgrade so I really
want to tune this server as well as possible. I have done the
following:
-Set the /gb switch in the boot.ini and set the cache allocation size
to 2gb
-Moved pagefile.sys to the SAN for better IO and enabled the use system
cache setting (i'm not sure if this is correct with the DB being on the
SAN?)

I'm sure i'm still a long way off getting it working properly though so
any advice would be greatly appreciated. These are some of the other
settings I'd really like some input on:
-Log Buffer Size
-Transaction Log Size
-Transaction Log Directory
-Working Log Directory

Thanks for reading!
James

You are correct, PSQL8 does NOT use log files in the same way as other
databases, and backups are done by copying the files off to tape -
-making them MUCH easier than other systems.

If you plan on backing up the system while users have files open, then
you'll want to have the Backup Agent to help with this -- a cheap
add-on product. (www.goldstarsoftware.com/buagent.asp) Otherwise,
you'll want to manually set up continuous operations mode -- see the
article here (www.goldstarsoftware.com/press.asp) on getting proper
backups.

As for performance, you'll want to have lots of memory on the server --
With Windows 2003 Advanced or Enterprise, go with as much as you can
afford. With Win2003 Standard, the max the OS will see is 4GB. The
database should be configured with 600MB to 800MB of cache, and for a
system with 4GB of memory, you'll want to DISABLE the L2 cache (Max
Microkernel Memory Usage = 0) and ENABLE the OS cache (System Cache =
ON) for best results.

In the disk channel, be sure to set up a striped and mirrored set of
drives (RAID10) for the database files. If you can put a simple stripe
for the Transaction logs, this is helpful, otherwise go with a single
drive. Also, set up your SAN with a configuration of 80% memory set
for write caching, and 20% for read or read-ahead caching. Having
multiple FC I/O channels can certainly help, as well.


Beyond this, there is no one "right" answer for performance monitoring.
In fact, I recently helped a customer with a huge 8-way server, 32GB of
memory, and a big, fast SAN with 4 FC cards, and we ended up changing
some settings AWAY from what was normally considered optimal in order
to gain performance. Just remember that your mileage will vary, and
you should tune it for your own environment (and budget).
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - July 19-22 ***
*** Chicago: Pervasive DataExchange Class - July 27-29 ***





jrobertsatcorpnet.com.au wrote:

Thanks very much for your help.

Bill Bach wrote:

Sorry one more question. You said that having 4 gb is a limitation, I
don't really understand this as the NTBDSMGR.EXE process can only use
3gb (with the /3gb switch). So why would having more than 4gb be
beneficial? Also you said the
database should be configured with 600MB to 800MB of cache, I have set
this to 2gb and seen improvements, have I done the wrong thing?

Thanks again for your help.

Cheers,
James

Actually, what I said was:
"With Win2003 Standard, the max the OS will see is 4GB."

Windows 2003 STANDARD Servers cannot address more than 4GB of memory.
Advanced and Enterprise servers can see as much as you have. While the
database process itself cannot address the entire block of memory,
using a huge chunk of memory for the OS cache can eliminate disk
activity almost as effectively as the database cache, and you can even
forcably pre-load data into cache (via the XCOPY command), which is
something that you cannot easily do with the database cache.

As I also mentioned, every system is different. If you have best
performance with 2GB of L1 database cache, then go with it. I can only
comment on the large systems that I have seen and how we have tuned
them.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - July 19-22 ***
*** Chicago: Pervasive DataExchange Class - July 27-29 ***

jrobertsatcorpnet.com.au wrote: