PMFJI, but I'd like to expandon this a bit: "Fortier, Christi (USPC.PCT.Hopewell)" wrote: > I'll provide the 2x4 :}. Steve, there is alot of tuning work you can do, > but ultimately to get you running for testing, up your RAM to at least 200MB. First, I would not run the GUI tools on the server while active. This ensures that the Java run time environment is active and it "chews" up several MB of memory. Run the tools from an Admin. Wkstn. > Run the following: > > db2 update dbm cfg using numdb 2 (alot of memory calculations are based on > this...if you are keeping sample database use 2, otherwise 1 after you drop > Sample) This applies only if you intend to activate both db's concurrently. If you plan to activate only one db at a time, you can set numdb to whatever. It controls the number of concurrently activated db's. > db2 update dbm cfg using maxagents 100 (reduce to at least 1/2 of > defaults..reducing the number of connections..impacts memory) I think this should refer to max_coordagents, they control the connections. maxagents includes those plus all the agents that db2 runs internally itself. What really controls the workload is maxCagents. This controls the number of concurrently executing agents int the instance (meaning they're running an SQL statement or command as opposed to just being connected and waiting between statements). > db2 update dbm cfg using num_poolagents 100 (keep in sync w maxagents This may be a bit much for this smal a system. Pool agents keep a minimum of private resources assigned to them at the expense of others. If pool agents are to small, you pay a quick hit to get the agent built and assigned if maxagents is not reached. 100 seems high to me and given how small the system is in memory, I would not expect you'd need more than 15 or 20. > db2 update dbm cfg using num_initagents 0 See, this is good. Init agents are genrated at db2start and sit therre idle until required. You might as well pay a longer connect cost (millisecs) to get the agent generated and not pay the resource cost of having it sit idle. > db2 update dbm cfg using sheapthres 2500 (reduces the overall sortheap) > Now play... > Create your DB dbname, then..... > db2 update db cfg for dbname using sortheap 128 (per connection memory) > db2 update db cfg for dbname using buffpage 128 (definitely tune up later) Here you can use a gross rule of thumb. Look at NT task manager once the instance isstarted and before activating and/or connecting to the db. This will show you how much memory is committed and therefore left. Use 50% of this to size your Buffer Pool if your table are in the 10K+ rows. At 100 char/row, this takes 250 buffer pool page for that table. Granted the pages are replacable, but many tables will create a lot of traffic on a 128 page buffer pool. > > db2 update db cfg for dbname using util_heap_sz 1000 (definitely tune up for > bkup, loads, reorgs, runstats etc.) In your case of a small memory system, I'd run while there are no connections for db backup/restore and only yours for tablespace backup/restore or reorgs, runstats. utilities. When there are no connections on the db, the buffer pool pages will claimed by the util_heap which is used as buffer space for b'up/rest. this means that you could set the heap size to the same size as your bp. Reset it after running the utilities. For on-line b'up and tblsp b'up/rest online, then try to run this at lowest level of utilization. Asmaller claim on the bp will be made and you can use more space for the heap size. DB2 will deal with this dynamically. > clipped..... > HTH, Pierre.
begin:vcard n:Saint-Jacques;Pierre tel;cell:514-233-8679 tel;fax:514-737-1268 tel;work:514-737-4515 x-mozilla-html:FALSE org:SES Consultants Inc. adr:;;233 Simcoe Cr.;Mount-Royal;QC;H3P 1X1;Canada version:2.1 email;internet:[EMAIL PROTECTED] title:President fn:Pierre Saint-Jacques end:vcard
