New post
User bio
404 bio not found
Member since May 17, 2016
Posts:
show all 1
Replies:
show all 25
Chad Severtson · Oct 30

A few thoughts: 

  1. I consider <FILEFULL> or <DSKFUL> errors to be risks for data integrity -- the system is unable to write everything attempted. This is less of a risk with IRISTEMP, especially if the entire instance fails. However, if other databases are affected, you may have some physical or logical data integrity issues to resolve. 
  2. Check your SQL query plans. I suspect you're generating some large temp tables if your IRISTEMP is the database that is filling up your disk. 
  3. IRISTEMP is special -- it tries to keep the blocks in memory as much as possible before writing them out to the disk. If you're exhausting your disk space because IRISTEMP grew too large, then Alexander is correct: some additional global buffers could help. However, if your load exceeds your capacity, the bag will eventually burst. 
  4. Setting a Maximum Size for IRISTEMP will not completely resolve the issue. However, it may make the situation more readily recoverable. If your IRISTEMP is on the same filesystem as your OS, it can be more difficult to recover without a restart. 
  5. Consider setting MaxIRISTempSizeAtStart to be be able to recover more readily by automatically reducing the size of IRISTEMP
Chad Severtson · Oct 20

I'd love to know more about your specific use case for using 32KB blocks for the database. In my experience, 8KB blocks are generally more adaptable unless you're exclusively working with atomic data elements that are that size or larger. IMHO, it's an instance wide consideration rather than only a database level consideration because allocating buffers of 32KB reserves a portion of the memory for blocks of that size. 

Certifications & Credly badges:
show all 4
Global Masters badges:
show all 2
Followers:
show all 1
Ashok K.
Following:
Chad has not followed anybody yet.