The stats shown look generally ok, no big red flags, other than 14 GB being potentially a somewhat small buffer pool. But that depends a lot on what data the application reads. The ratio of logical to physical reads shown is good, but of course that is something can vary significantly from one moment to the next. It would be interesting to see whether it remains high over time. If not, a -B increase may be in order, resources permitting.
Set -omsize above 2623; you might even be able to change it online with proutil -increaseto (I've had mixed success with that). But once set, it's a quick win in terms of reducing read overhead. As far as changing DB configuration generally is concerned, it's a good idea to consult with your vendor on any changes you plan to make. But it's also a good idea for them to listen to you and not be married to boilerplate settings.
Re: confidentiality, I don't think database structure qualifies as intellectual property. Also, it's your database, not the vendor's. Those are just my personal opinions, not my employer's (I work for an application partner), and I'm not a lawyer. But I do understand that you have to get buy-in from other people before disclosing that information. Fair enough. The important thing is that someone is looking after this database and they understand modern storage-design best practices. Based on what you've described, the structure sounds reasonable. But the devil's in the details. There can be efficiency issues lurking in otherwise reasonable structure/schema assignments.
I really strongly encourage adding -tablerangesize and -indexrangesize with appropriate values. Note though that with a fairly large schema and user count this change will somewhat increase your shared memory size. Test-start a schema holder DB on a test box with your production params to see how much of a change it is for you. Once you restart your prod DB with these params, start looking at your CRUD stats. You might learn a lot of interesting things about your application.
You'll also be better informed about whether certain aspects of your DB configuration are appropriate.
Finding appropriate values:
Code:
find dictdb._statbase no-lock.
find last dictdb._file no-lock where _file._tbl-type = "T" use-index _file-number.
find last dictdb._index no-lock where not _index._index-name begins "_" use-index _index-number.
display
"Current -basetable : " _statbase._tablebase skip
"Current -baseindex : " _statbase._indexbase skip
"Highest table number: " _file._file-number format "->>>>>>>>>9" skip
"Highest index number: " _index._idx-num format "->>>>>>>>>9" skip
"Min -tablerangesize : " _file._file-number - _statbase._tablebase + 1 format "->>>>>>>>>9" skip
"Min -indexrangesize : " _index._idx-num - _statbase._indexbase + 1 format "->>>>>>>>>9" skip
with no-labels.
We are in a VMware environment and the database is sharing IO with other databases and applications. The disks of this system are all currently using the same type of storage on the vm hosts. Moving the after image file system/disk to storage optimized for database log files is on our todo list.
That's good, though it begs the question, where are they now? On a NAS?
Also, keeping AI areas, local backups, and local AI archive physically and logically separate from the database extents isn't just a performance optimization, it can reduce the damage caused by hardware/software/meatware problems. If the AI partition goes away, you still have your DB. If your DB partition goes away, you still have everything you need to recover it. But if they're all together in one place...