9.1 Woes... Recommendations appreciated!

[Zebwen]

Apologies if this is in the wrong place, just sticking some feelers out for a bit of information if possible.

We have a product from a vendor who has provided us with a database and client solution both running on 9.1D SP8, we have had this product for around 3 years and are unfortunately financially tied in. We have untold issues with the system in general, and have been battling to try and identify where these issues might lie.

After a lot of battling, we have finally managed to get the vendor agree to let us install 9.1E on the client machines (in an attempt to troubleshoot speed issues on the clients and eliminate the version of Progress as the cause), but they will not agree to anything above 9.1D SP9 on the server as they do not support it. In addition to this they will not provide us with a copy of 9.1E SP4 to install on the clients, as they also do not support SP4, only a standard 9.1E client installation (we do not have access to the Progress download portal to get this ourselves)...

Neither myself or my colleagues that maintain the tin that this sits on are DB admins (let alone Progress DB admins), although we are trying our best to diagnose speed and stability issues that we are having. Each time we speak to our Vendor, they blame the Virtual Server that it is sat on (not enough memory, disk issues, etc... All of which have been thoroughly tested and ruled out). We are swiftly coming to the conclusion that unfortunately the Vendor no longer employs anyone as a full-time Progress professional, although they do manage to stumble along using this old version with which they are comfortable.

Does anyone have a recommendation to aid us in our diagnostics? I know this is a very broad question and I apologise if I am being vague, I will of course provide specifics if required!

Fingers crossed in advance,

Zeb

 

[Cringer]

You sound like you're having a nightmare there.

First, and most important advice - get shot of that vendor as soon as you can. They sound horrendous and they give Progress a bad name.

Now for the more practical side of things...

1) Can you paste in the first 80 or so lines of your database server log, after the last restart of the database. That will contain all the relevant settings on the database.
2) Also, it would be helpful to know what sorts of things are running slowly.
3) As well as that, what OS is the server running, and what hardware does it have?
4) What Progress license are you running on the server?

That should help the good folks in the know point you in a better direction!

 

[Zebwen]

Thanks for the response! I will try and answer as best I can, kick me if I'm misunderstanding something!

1) First 95 lines after database startup:

09:33:14 BROKER  0: Multi-user session begin. (333)09:33:14 BROKER  0: Begin Physical Redo Phase at 0 . (5326)
09:35:22 BROKER  0: Physical Redo Phase Completed at blk 2853 off 2421 upd 17231. (7161)
09:35:22 BROKER  0: Started for 30000 using TCP, pid 2904. (5644)
09:35:22 BROKER  0: Connecting to Admin Server on port 7835. (8836)
09:35:22 BROKER  0: Registered with Admin Server. (8846)
09:35:22 BROKER  0: PROGRESS Version 9.1D on WINNT. (4234)
09:35:22 BROKER  0: Server started by SYSTEM on CON:. (4281)
09:35:22 BROKER  0: Started using pid: 2904. (6574)
09:35:22 BROKER  0: Physical Database Name (-db): E:\database. (4235)
09:35:22 BROKER  0: Database Type (-dt): PROGRESS. (4236)
09:35:22 BROKER  0: Force Access (-F): Not Enabled. (4237)
09:35:22 BROKER  0: Direct I/O (-directio): Not Enabled. (4238)
09:35:22 BROKER  0: Number of Database Buffers (-B): 300000. (4239)
09:35:22 BROKER  0: Maximum private buffers per user (-Bpmax): 64. (9422)
09:35:22 BROKER  0: Excess Shared Memory Size (-Mxs): 16465. (4240)
09:35:22 BROKER  0: The shared memory segment is not locked in memory. (10014)
09:35:22 BROKER  0: Current Size of Lock Table (-L): 32000. (4241)
09:35:22 BROKER  0: Hash Table Entries (-hash): 98407. (4242)
09:35:22 BROKER  0: Current Spin Lock Tries (-spin): 50000. (4243)
09:35:22 BROKER  0: Number of Semaphore Sets (-semsets): 1. (6526)
09:35:22 BROKER  0: Crash Recovery (-i): Enabled. (4244)
09:35:22 BROKER  0: Database Blocksize (-blocksize): 4096. (6573)
09:35:22 BROKER  0: Delay of Before-Image Flush (-Mf): 3. (4245)
09:35:22 BROKER  0: Before-Image File I/O (-r -R): Reliable. (4247)
09:35:22 BROKER  0: Before-Image Truncate Interval (-G): 60. (4249)
09:35:22 BROKER  0: Before-Image Cluster Size: 16777216. (4250)
09:35:22 BROKER  0: Before-Image Block Size: 16384. (4251)
09:35:23 BROKER  0: Number of Before-Image Buffers (-bibufs): 40. (4252)
09:35:23 BROKER  0: BI File Threshold size (-bithold): 0.0   Bytes. (9238)
09:35:23 BROKER  0: BI File Threshold Stall (-bistall): Disabled. (6552)
09:35:23 BROKER  0: After-Image Stall (-aistall): Not Enabled. (4254)
09:35:23 BROKER  0: After-Image Block Size: 16384. (4255)
09:35:23 BROKER  0: Number of After-Image Buffers (-aibufs): 40. (4256)
09:35:23 BROKER  0: Storage object cache size (-omsize): 1024 (8527)
09:35:23 BROKER  0: Maximum Number of Clients Per Server (-Ma): 4. (4257)
09:35:23 BROKER  0: Maximum Number of Servers (-Mn): 112. (4258)
09:35:23 BROKER  0: Minimum Clients Per Server (-Mi): 1. (4259)
09:35:23 BROKER  0: Maximum Number of Users (-n): 279. (4260)
09:35:23 BROKER  0: Host Name (-H): server. (4261)
09:35:23 BROKER  0: Service Name (-S): 30000. (4262)
09:35:23 BROKER  0: Network Type (-N): TCP. (4263)
09:35:23 BROKER  0: Character Set (-cpinternal): ISO8859-1. (4264)
09:35:23 BROKER  0: Parameter File: Not Enabled. (4282)
09:35:23 BROKER  0: Maximum Servers Per Broker (-Mpb): 50. (5647)
09:35:23 BROKER  0: Minimum Port for Auto Servers (-minport): 3000. (5648)
09:35:23 BROKER  0: Maximum Port for Auto Servers (-maxport): 5000. (5649)
09:35:23 BROKER  0: This broker supports 4GL server groups only. (8863)
09:35:23 BROKER  0: Large database file access has been enabled. (9426)
09:35:23 BROKER  0: Created shared memory with segment_id: 11599872 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 145817600 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 280035328 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 414253056 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 548470784 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 682688512 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 816906240 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 951123968 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 1085341696 (9336)
09:35:23 BROKER  0: Created shared memory with segment_id: 1219559424 (9336)
09:35:23 SRV     1: Started on port 3000 using TCP, pid 2488. (5646)
09:35:24 SRV     1: Login usernum 389, userid user1, on comp00667. (742)
09:35:24 SRV     2: Started on port 3001 using TCP, pid 1804. (5646)
09:35:25 SRV     2: Login usernum 388, userid user2, on comp00632. (742)
09:35:25 SRV     3: Started on port 3003 using TCP, pid 2832. (5646)
09:35:26 SRV     3: Login usernum 387, userid user5, on comp00664. (742)
09:35:26 BROKER  4: Started for 30050 using TCP, pid 2808. (5644)
09:35:26 BROKER  4: This is an additional broker for this protocol. (5645)
09:35:26 BROKER  4: This broker supports SQL server groups only. (8864)
09:35:28 BIW   112: Started. (2518)
09:35:30 AIW   113: Started. (2518)
09:35:32 WDOG  114: Started. (2518)
09:35:34 APW   115: Started. (2518)
09:35:36 APW   116: Started. (2518)
09:35:38 APW   117: Started. (2518)
09:35:40 APW   118: Started. (2518)
09:35:40 SRV     2: Logout usernum 388, userid , on comp00632. (739)
09:35:49 SRV     2: Login usernum 388, userid user2, on comp00632. (742)
09:36:05 SRV     5: Started on port 3005 using TCP, pid 2420. (5646)
09:36:06 SRV     5: Login usernum 386, userid user3, on comp00626. (742)
09:36:09 SRV     1: Logout usernum 389, userid , on comp00667. (739)
09:36:15 SRV     1: Login usernum 389, userid user4, on comp00667. (742)
09:36:19 SQLSRV2 6: SQL Server 9.1D.09 started, configuration: "database.defaultconfiguration" 
09:36:19 SQLSRV2 6: "SQL" started on port 3008, pid 3380 (0x00000d34).
09:36:19 SQLSRV2 6: Thread stack size: 1024000 (bytes).
09:36:19 SQLSRV2 6: DLC from ENVIRONMENT VARIABLE is: C:\Program Files\PROGRESS 
09:36:19 SQLSRV2 6: WRKDIR from REGISTRY is: C:\PROGRESS\WRK\ 
09:36:19 SQLSRV2 6: JDKHOME from REGISTRY is: C:\Program Files\PROGRESS\jdk 
09:36:19 SQLSRV2 6: JREHOME from REGISTRY is: C:\Program Files\PROGRESS\jre 
09:36:19 SQLSRV2 6: CLASSPATH from DEFAULT is:  
09:36:19 SQLSRV2 6: PROSQL_LOCKWAIT_TIMEOUT value is: 5 seconds
09:36:20 SRV     7: Started on port 3009 using TCP, pid 3396. (5646)
09:36:20 SQLSRV2 6: Login usernum 385, remote SQL client. (8873)
09:36:20 SQLSRV2 6: Usr 385 set name to sysprogress. (7129)
09:36:21 SRV     7: Login usernum 384, userid Admin, on comp00734. (742)
09:36:24 SRV     8: Started on port 3010 using TCP, pid 3384. (5646)

2) Pushing and pulling data to and from the DB is slow, SQL-based (ODBC connected) queries are also extremely slow. Under medium load, the clients (currently running 9.1D SP9) are also very slow to gather data, and they are just pulling back individual clients records for the most part. Opening the client query screen takes around 1 second under normal situations, but this can push up to 30 seconds (just to open the dialogue) if the DB is busy (and we are having trouble tracking down what "busy" means in general).

3) Server is a hosted VM (VMWare) Win 2003 SP4 (x86 Enterprise) - Allocated 12gb RAM and 2 cores of x7350 Xeon 2.93GHz

4) License is 9.1D Enterprise DB Networking License + 9.1D Client Networking

Hope that helps!

Zeb

 

[tamhas]

Many otherwise reasonably competent vendors, especially small ones, don't employ anyone that is good at tuning performance in customer production systems. I would suggest seeking out a consultant ... some post on this forum ... and bring them in for a diagnosis and then maintain a relationship for issues on an on-going basis.

Installing a system on 9.1D only three years ago is a sign of an application which was written years ago and which is only barely being maintained. There is absolutely no reason for you not to be on at least 10.1, if not 10.2. In fact, when you were sold the system, 9.1D was not even a supported release.

 

[TomBascom]

Your vendor needs to be shown the light...

Do you have source code?

When was the last time you dumped and loaded?

Are you using storage areas? (Do a "prostrct list" and then show your .st file...)

Have you ever run UPDATE STATISTICS on the SQL side?

 

[Zebwen]

Hi Tom,

Unfortunately no, we do not have access to the source code (although I believe there is an escrow agreement in place should the vendor go bump).

Last dump & load was July 2011.

database.st

#b E:\database.b1 f 1024000
b E:\database.b2 f 1024000
b E:\database.b3
#
d "Schema Area":6,32 E:\database.d1
#
d "Data Area":7,32 E:\database_7.d1 f 2048000
d "Data Area":7,32 E:\database_7.d2 f 2048000
d "Data Area":7,32 E:\database_7.d3 f 2048000
d "Data Area":7,32 E:\database_7.d4 f 2048000
d "Data Area":7,32 E:\database_7.d5
#
a e:\database\database.a1
#
a e:\database\database.a2
#
a e:\database\database.a3
#
a e:\database\database.a4
#
a e:\database\database.a5
#
a e:\database\database.a6
#
a e:\database\database.a7
#
a e:\database\database.a8
#
a e:\database\database.a9
#
a e:\database\database.a10
#
a e:\database\database.a11
#
a e:\database\database.a12
#
a e:\database\database.a13
#
a e:\database\database.a14
#
a e:\database\database.a15
#
a e:\database\database.a16
#
d "Area8":100,8 E:\database_100.d1 f 128000
d "Area8":100,8 E:\database_100.d2
#
d "Area32":102,32 E:\database_102.d1 f 1024000
d "Area32":102,32 E:\database_102.d2
#
d "Area64":103,64 E:\database_103.d1 f 2048000
d "Area64":103,64 E:\database_103.d2
#
d "AreaDT":104,32 E:\database_104.d1 f 8192000
d "AreaDT":104,32 E:\database_104.d2 f 8192000
d "AreaDT":104,32 E:\database_104.d3 f 8192000
d "AreaDT":104,32 E:\database_104.d4 f 8192000
d "AreaDT":104,32 E:\database_104.d5 f 8192000
d "AreaDT":104,32 E:\database_104.d6
#
d "AreaNT":105,32 E:\database_105.d1 f 2048000
d "AreaNT":105,32 E:\database_105.d2 f 2048000
d "AreaNT":105,32 E:\database_105.d3 f 2048000
d "AreaNT":105,32 E:\database_105.d4 f 2048000
d "AreaNT":105,32 E:\database_105.d5 f 2048000
d "AreaNT":105,32 E:\database_105.d6
#
d "AreaRT":106,128 E:\database_106.d1 f 1024000
d "AreaRT":106,128 E:\database_106.d2 f 1024000
d "AreaRT":106,128 E:\database_106.d3 f 1024000
d "AreaRT":106,128 E:\database_106.d4
#
d "AreaRev":107,64 E:\database_107.d1 f 512000
d "AreaRev":107,64 E:\database_107.d2
#
d "Area128":108,128 E:\database_108.d1 f 1024000
d "Area128":108,128 E:\database_108.d2
#
d "AreaReview":109,32 E:\database_109.d1 f 512000
d "AreaReview":109,32 E:\database_109.d2
#
d "AreaPool":110,32 E:\database_110.d1 f 512000
d "AreaPool":110,32 E:\database_110.d2
#
d "IndexArea":200,32 E:\database_200.d1 f 512000
d "IndexArea":200,32 E:\database_200.d2 f 512000
d "IndexArea":200,32 E:\database_200.d3 f 512000
d "IndexArea":200,32 E:\database_200.d4
#
d "IndexDT":201,32 E:\database_201.d1 f 4096000
d "IndexDT":201,32 E:\database_201.d2 f 4096000
d "IndexDT":201,32 E:\database_201.d3 f 4096000
d "IndexDT":201,32 E:\database_201.d4 f 4096000
d "IndexDT":201,32 E:\database_201.d5 f 4096000
d "IndexDT":201,32 E:\database_201.d6
#
d "IndexNT":202,32 E:\database_202.d1 f 2048000
d "IndexNT":202,32 E:\database_202.d2 f 2048000
d "IndexNT":202,32 E:\database_202.d3
#
d "IndexRT":203,32 E:\database_203.d1 f 512000
d "IndexRT":203,32 E:\database_203.d2 f 512000
d "IndexRT":203,32 E:\database_203.d3 f 512000
d "IndexRT":203,32 E:\database_203.d4
#
d "IndexArea2":204,32 E:\database_204.d1 f 512000
d "IndexArea2":204,32 E:\database_204.d2
#
d "IndexReview":205,1 E:\database_205.d1 f 512000
d "IndexReview":205,1 E:\database_205.d2
#
d "IndexPool":206,1 E:\database_206.d1 f 512000
d "IndexPool":206,1 E:\database_206.d2
#
d "instplan_data":300,64 E:\database_300.d1 f 2048000
d "instplan_data":300,64 E:\database_300.d2 f 2048000
d "instplan_data":300,64 E:\database_300.d3 f 2048000
d "instplan_data":300,64 E:\database_300.d4 f 2048000
d "instplan_data":300,64 E:\database_300.d5 f 2048000
d "instplan_data":300,64 E:\database_300.d6 f 2048000
d "instplan_data":300,64 E:\database_300.d7
#
d "instplan_index":301,64 E:\database_301.d1 f 1024000
d "instplan_index":301,64 E:\database_301.d2 f 1024000
d "instplan_index":301,64 E:\database_301.d3
#
d "prochistory_data":302,64 E:\database_302.d1 f 1024000
d "prochistory_data":302,64 E:\database_302.d2 f 1024000
d "prochistory_data":302,64 E:\database_302.d3 f 1024000
d "prochistory_data":302,64 E:\database_302.d4 f 1024000
d "prochistory_data":302,64 E:\database_302.d5 f 1024000
d "prochistory_data":302,64 E:\database_302.d6 f 1024000
d "prochistory_data":302,64 E:\database_302.d7 f 1024000
d "prochistory_data":302,64 E:\database_302.d8
#
d "prochistory_index":303,64 E:\database_303.d1 f 512000
d "prochistory_index":303,64 E:\database_303.d2 f 512000
d "prochistory_index":303,64 E:\database_303.d3 f 512000
d "prochistory_index":303,64 E:\database_303.d4
#
d "exportcontrol_data":304,64 E:\database_304.d1 f 1024000
d "exportcontrol_data":304,64 E:\database_304.d2 f 1024000
d "exportcontrol_data":304,64 E:\database_304.d3 f 1024000
d "exportcontrol_data":304,64 E:\database_304.d4
#
d "exportcontrol_index":305,64 E:\database_305.d1 f 512000
d "exportcontrol_index":305,64 E:\database_305.d2
#
d "addressee_data":306,64 E:\database_306.d1 f 512000
d "addressee_data":306,64 E:\database_306.d2 f 512000
d "addressee_data":306,64 E:\database_306.d3
#
d "addressee_index":307,64 E:\database_307.d1 f 512000
d "addressee_index":307,64 E:\database_307.d2
#
d "sundryinfo_data":308,64 E:\database_308.d1 f 512000
d "sundryinfo_data":308,64 E:\database_308.d2 f 512000
d "sundryinfo_data":308,64 E:\database_308.d3 f 512000
d "sundryinfo_data":308,64 E:\database_308.d4 f 512000
d "sundryinfo_data":308,64 E:\database_308.d5
#
d "sundryinfo_index":309,64 E:\database_309.d1 f 256000
d "sundryinfo_index":309,64 E:\database_309.d2
#
d "debt_data":310,64 E:\database_310.d1 f 1024000
d "debt_data":310,64 E:\database_310.d2 f 1024000
d "debt_data":310,64 E:\database_310.d3 f 1024000
d "debt_data":310,64 E:\database_310.d4
#
d "debt_index":311,64 E:\database_311.d1 f 512000
d "debt_index":311,64 E:\database_311.d2 f 512000
d "debt_index":311,64 E:\database_311.d3 f 512000
d "debt_index":311,64 E:\database_311.d4
#
d "client_data":312,64 E:\database_312.d1 f 512000
d "client_data":312,64 E:\database_312.d2 f 512000
d "client_data":312,64 E:\database_312.d3 f 512000
d "client_data":312,64 E:\database_312.d4
#
d "client_index":313,64 E:\database_313.d1 f 256000
d "client_index":313,64 E:\database_313.d2 f 256000
d "client_index":313,64 E:\database_313.d3 f 256000
d "client_index":313,64 E:\database_313.d4 f 256000
d "client_index":313,64 E:\database_313.d5 f 256000
d "client_index":313,64 E:\database_313.d6
#
d "pro2sql_data":314,64 E:\database_314.d1 f 512000
d "pro2sql_data":314,64 E:\database_314.d2 f 512000
d "pro2sql_data":314,64 E:\database_314.d3 f 512000
d "pro2sql_data":314,64 E:\database_314.d4 f 512000
d "pro2sql_data":314,64 E:\database_314.d5 f 512000
d "pro2sql_data":314,64 E:\database_314.d6
#
d "pro2sql_index":315,64 E:\database_315.d1 f 512000
d "pro2sql_index":315,64 E:\database_315.d2 f 512000
d "pro2sql_index":315,64 E:\database_315.d3 f 512000
d "pro2sql_index":315,64 E:\database_315.d4

UPDATE STATISTICS was run but apparently this was many moons ago (I am being informed by my colleague who has been with the company longer than myself).

Hope that helps!

Zeb

 

[Rob Fitzpatrick]

Well, some amount of tuning effort has been put into this database in the past, given the number of settings that are at non-default values, the liberal use of storage areas, and the fact that after-imaging is enabled (all good). I also see areas labeled "pro2sql", which I believe is a BravePoint product for replication to SQL Server. Do you use that?

I can't judge whether your user settings are correct, not knowing much about your clients.

• Are all of your clients remote, i.e. connecting to the DB via TCP, or do you also have some clients that run directly on the database server?
• What OS do the clients run on?
• How many ABL clients do you want your DB to be able to handle concurrently at peak?
• How many SQL clients, at peak?
• How large is your database?
• What kind of storage is your database on? (disk type, disk capacity, number of spindles, spindle speed, RAID implementation if any, etc.)
• What is the SLA for the availability of your application; is it Mon - Fri business hours, or 24/7/365?

I recommend that you learn how to run UPDATE STATISTICS, and do so more often than once in "many moons". I also agree with Thomas that your company could definitely benefit from some professional help.

 

[cj_brandt]

I would recommend running windows perfmon to get an idea if the OS is causing some bottlenecks.
Agree with UPDATE STATS, but you are on 9.x so SQL performance will never be good.

You could also run proutil <dbname> -C tabanalys and send the output to a file. Since you are using Type I Storage Areas, fragmentation and scatter factor will matter.

 

[Zebwen]

Well, some amount of tuning effort has been put into this database in the past, given the number of settings that are at non-default values, the liberal use of storage areas, and the fact that after-imaging is enabled (all good). I also see areas labeled "pro2sql", which I believe is a BravePoint product for replication to SQL Server. Do you use that?

I can't judge whether your user settings are correct, not knowing much about your clients.

• Are all of your clients remote, i.e. connecting to the DB via TCP, or do you also have some clients that run directly on the database server?
• What OS do the clients run on?
• How many ABL clients do you want your DB to be able to handle concurrently at peak?
• How many SQL clients, at peak?
• How large is your database?
• What kind of storage is your database on? (disk type, disk capacity, number of spindles, spindle speed, RAID implementation if any, etc.)
• What is the SLA for the availability of your application; is it Mon - Fri business hours, or 24/7/365?

I recommend that you learn how to run UPDATE STATISTICS, and do so more often than once in "many moons". I also agree with Thomas that your company could definitely benefit from some professional help.

Hi! Sorry for the delayed response!

• All clients are remote, although there are some scripted processes that run directly on the server (through scheduled tasks).
• Clients are primarily running on Windows XP, and a handful of Windows 7 machines.
• If by ABL you mean 4GL then it is 100 concurrent connections at peak.
• For SQL connections it can fluctuate between 5 and around 20 at peak.
• DB is 140gb.
• Disk type is SAS, 4 Spindles, 15k speed, raid 1/0 on a fibrechannel EMC SAN, the virtual host has been allocated 500gb for this drive.
• Application availability is Mon-Fri 7am to 8:30pm, and Sat 8am to 12:30pm, although there are tasks that run against the DB and reports that access it at varying times outside of business hours. The only real Maintenance window for this DB is Saturday 6pm through Sunday until about 9pm.

I would recommend running windows perfmon to get an idea if the OS is causing some bottlenecks.
Agree with UPDATE STATS, but you are on 9.x so SQL performance will never be good.

You could also run proutil <dbname> -C tabanalys and send the output to a file. Since you are using Type I Storage Areas, fragmentation and scatter factor will matter.

Full DB Analasys (includes the tabanalys) is attached!

Could anyone please confirm the correct syntax for the update statistics command?

Thanks for replying!

Zeb

 

[Cringer]

From here: http://www.progresstalk.com/showthread.php?101407-Monitoring-query-Execution-in-Progress-8

Syntax: UPDATE STATISTICS for pub.tablename

 

[cj_brandt]

I think disk IO will be your main hurdle - you have 1.2gb of memory buffers for 140gb of data.
Do you track disk io and other OS stats with perfmon ?

Do you know which tables are the most often read ?
Some tables have a lot of indexes - over 10 and one had 20. I would think updates to these tables could be slow.
In some areas data and indexes are combined. You may want to create a new area to separate those.

 

[Rob Fitzpatrick]

You can connect to your database in an editor session (assuming you have a development license) and run the following program to generate a SQL stats update script:

/* Generate a SQL UPDATE STATISTICS script to be run from SQL Explorer.
   
   From KB article P115266
   
   To run the output of this program:
   sqlexp -char -db <dbname> -S <SQL broker port> 
      -infile UpdateStatistics_<dbname>.sql 
      -outfile UpdateStatistics.out 
      -user <username> -password <userpassword>
    
   where <username> is a DB user with SQL access
   
   Note: you must connect first to the DB in question, and it must be the 
         first (or only) DB connected, due to the ldbname( 1 ) in the file name
*/

OUTPUT TO value( "UpdateStatistics_" + ldbname( 1 ) + ".sql" ).

FOR EACH _File NO-LOCK WHERE _Tbl-Type = "T":
    PUT UNFORMATTED "UPDATE TABLE STATISTICS AND INDEX STATISTICS AND ALL COLUMN STATISTICS FOR PUB." quoter( _File._File-Name )";" SKIP.
    PUT UNFORMATTED "COMMIT WORK;" SKIP.
END.

OUTPUT CLOSE.

Then run the resulting SQL file with SQL Explorer to update the statistics.

Disclaimer: I haven't run this in 9.1D.