The first best practice is to plan and *test* these things before you implement.
This sounds like typical performance of SAN infrastructure. The second best practice is to not use a SAN for your database. SANs are notoriously terrible for performant database storage. SANs are *shared* and they live on a *network*. Neither of those characteristics are beneficial for IO performance.
If you want your database to go fast you should implement your database on dedicated internal SSD storage. On AIX use a jfs2 filesystem.
If you don't care about performance or cost and wish to maximize the salaries and bonus pool available for SAN sales people etc then go out and buy a SAN. Go with "all flash". It won't be any faster but it will cost a whole lot more and the sales guy might buy you a nice lunch. Make sure he tips the wait staff generously.
Also make sure to prohibit the use of Jumbo Frames. All of your network infrastructure supports them but there is no point in implementing them because some random bit of gear somewhere might, maybe, have a default MTU of 1500 and it would just be too much trouble to find it and change it.
If you *must* have a SAN then make sure you have enough RAM to render its terrible performance (mostly) moot. (Usually that means that you will want to set -B to roughly 100% of the db size.) It still won't help with operations that are necessarily disk bound like committing huge updates, rebuilding indexes, restoring and roll forward etc. That will be very unfortunate when something bad happens and you need to recover and everyone is asking why it is taking so long but, if you're lucky, that won't happen every week. (It will only happen around 4:45pm on the day when you are (were) leaving for a nice relaxing vacation...)
Or you could spend lifetimes arguing about kernel and filesystem parameters that won't ever actually make a noticeable difference. Or you could try to get the SAN admin to actually pay attention to latency and end to end performance instead of hiding behind irrelevant bullshit like gigabytes per second or internal utilization metrics that assume requests arrived in zero nanoseconds and that results are returned before they are requested. (Meanwhile the users will be plotting a revolt...)
