I do not see any clear advantages for putting the Central Objects database on the deployment server. Depending on your disk space availability I guess one benefit might be that you could use space on relatively cheap Intel platform disks while saving space on more expensive enterprise server hardware. (I am assuming your enterprise server is AS400 or Unix)
Disadvantages would be slower package build performance and additional maintenance tasks.
During package builds, the Central Objects are read and the information written to the TAM files in the package directory. This is an I/O and CPU intensive process. As you would be reading from the database and writing to the TAM files in the package directory, you would probably have I/O contention during package builds. In the past this was the standard setup for the AS/400 platform. In prior AS/400 releases you could not store the Central Objects tables in DB2/400 due to limited BLOB field support. This setup worked (works) fine but was slow during package builds.
From a maintenance standpoint you would have added another database to keep up with. The Central Objects should be treated as critical production data. You would need to perform proper database backups on both the Deployment server and Enterprise server.
I can't agree with your point of slower package build times. The thing
is, when a package is built on the deployment server, the data is
retrived from Central Objects. If database is on the same machine where
build takes place, it eliminates network use. If you have a double
processor machine with separate disks for packages and database, there
should not be a penalty in terms of CPU use or disk. Also, from my
experience with B7332, a full client/server package without recompile
runs in under 2 hours on a lowly Intel SQL (PIII-500, , single IDE disk)
which runs both as deployment and enterprise server (one of our
sandboxes). A full client-only package is taking about 4 hours, when it
is built on the following config: Enterprise (HPUX, Oracle, 3-way, 3Gb
RAM, RAID), Deployment (Intel, 2-way, 512(?)RAM, RAID) over 100Mbit
connection (they are on the same switch). I would imagine a modern
AS/400 (iSeries) in a similar config would be anyhting from 6 to 12
hours (this, if everything is properly tuned up, it would be 6, but
longer is much more probable)
On the other hand, I do not think that faster package build times
justify additional costs, mostly in terms of maintenance.
My set of pro's and con's:
Cheaper platform (Intel), which, for 1W provides more "bang per buck"
Faster package build times
Separate maintenance of data and programs (Central Objects are on the
same server as pathcode, which you have to back up anyway).
Backups can be scheduled separately, less often then production data
You save precious disk space on production machine
You need a more powerful deployment server
You have to buy SQL server, which IS a different RDBMS from Oracle or
You have to maintain, tune and secure this new RDBMS
If your deployment server fails, only clients with full packages can
continue to work without interruption (partial will only be able to use
functionality, which already has been installed)
Backups of deployment server are more important then in the case of only
pathcode backups (C functions tend to change less frequently then the
specifications, which change every time you create version or change
If your enterprise server is Intel (especially SQL) and network is good,
it does not make sense to move CO to deployment. If network is not good
- improve it.
If your enterprise is Unix or AS/400, then depending on lack of HD space
on it, power of your deployment server, availability of SQL Server
licenses and IT staff to maintain it, you may consider moving CO to
B7332, XE (mostly XE at the moment); SQL 7.0, Oracle 8.1.5 (mostly SQL);
Wintel, HP (mostly Wintel)
Re: RE: Central Objects Databases on Deployment Server
I had assumed that the deployment server did not have separate disks for the database and a multi-channel RAID controller. My comments were based on a relatively standard spec NT box with 1 or 2 cpu's and (maybe) a single channel RAID 5 controller.
If one is willing to pour money into the deployment server then I totally agree that you can achieve better performance for package builds by running Central Objects on the deployment server.
The advantages to have the CO in the Deploymennt server instead of the
AS/400 is principaly the performance. The BLOW fields in the AS/400 have an
terrible performance when you try to do an check out or even while the
system is doing an JITI. You can take more than 5 minutes to do the check
out from the CO in an AS/400 (depend on the object, of course). Also take
more time to build a package, and avery job related with CO.
Disadvantages of putting Central Objects on the Deployment :
a) One more DBMS to buy
b) One more DBMS to backup and maintain
c) 20 extra Gb for the Deployment disk (not so expensive today...)
d) Some more extra RAM for the Deployment too.
e) You're tied to choose either MSSQL or Intel Oracle running on NT/W2K.
Advantages of putting Central Objects on the Deployment :
a) Objects load separated from Data load
b) Packages run faster (their data, Central Objects, is locally stored)
B7321 to Xe, NT/W2K/SQL
MCDBA,MCP+I,MCSE,Citrix Admin firstname.lastname@example.org
Grupo ASSA - Application Software SA
I assume below that you are referring to BLOBs below.
If you are having poor Central Objects performance,
make sure your ODBC for Central Objects is using data
compression. This will without a doubt improve
Central Objects performance on the AS/400 to at least
an acceptable level of slow.
You may also toy with changing block sizes and data
compression for other data sources.