I have seen this when you get too close to memory or tablespace thresholds on the Windows platform in UDB v7 fp5 - 7. The bug is recent as I did not see it in UDB v5 fp7 - fp13. Can't vouch for V6 since we went right from v5 to v7. Until they come with a fix, best bet to keep tablespace in use at < 80% of allocated. Good rule of thumb for reorgs anyway is to keep at 50% so reorg processes write locally rather than going out to temporary reorg files. Also, a well tuned database is less apt to go down. Check your memory configs(ie: buffpage(+ npages in syscat.bufferpools) , util_heap_sz, sortheap, sheapthresh, dbheap, numdb ...) ensure they are not allowing the database to max out your available memory. With EEE intra_parallel is important...turn off if you want the best of all of your processes, on if you are doing single process activity (backups, restores ...).
Regarding EEE on Regatta, I have met quite a few at IDUG that have EEE installations this large. With the Regatta, I expect you are using AIX? AIX has a larger EEEinstall base than windows if you like comfort in numbers. Every platform has pluses & limitations. Mainframes have a higher out of pocket cost, but they have alot of built in facilities to keep them up. You don't need to get another machine to keep production shielded from development and you can prioritize partitions. With mainframes, you do have to plan for the next 5 or 10 years down the road up front. There are expandability options, but at last check, they are usually costly & impact a greater number of users when you upgrade(correct me here, while I grew up with mainframes, I have been only remotely involved with mainframes for a few years). EEE on Windows & Unix is very fast, flexible, expandable as needed & cost effective. Windows & Unix UDB operate as great democratic societies where processes operate round robin. You isolate development from production on a different machine and usually different networks and domains prioritizing architecturally with more RAM, faster switches & faster IO (esp SANs). In Windows, if a physical node becomes unavailable through a switch hic cup, even for a nanosecond & you don't have failover set, UDB EEE tends to put that node in crash recovery too soon in my opinion. This can be offset by reliable switches & instantaneous failover on your switches between nodes at the hardware & software level. If the politics is such that you have only so many operators per machine, the cost of ownership can be expensive if you choose several physical nodes(spread across servers with fewer CPUs to take advantage of the additional megahertz). Another factor to consider is in switch & database technology, your going to only be able to go as fast as your slowest node, so until this changes you may need to ugrade your switch fabric. Regardless, if you throw the latest disk technologies & memory at the database, the database is extremely appreciative. You can also resolve to put the UDB database on 1 mega CPU server (sort of like a mainframe mimic), but then they cost more & you don't need EEE so much as EE in V7 takes advantage of multiple CPUs. So, as usual the answer depends on your environmental factors. Good Luck, I apologize for long winded note, & hope it helps. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 7:04 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Pendlebury-Bowe, Leslie; [EMAIL PROTECTED] Subject: [DB2EUG] DB2 EEE V7 FP8 Crashing We are about to implement a very large Data Warehouse in DB2 EEE on a Regatta machine. As we have been working with what I call little DB2 (as opposed to big DB2 Mainframe OS/390), I am seeing that we have many cases where we are forced to recover the entire Database because DB2 crashes for various reasons. The most recent example of what I am talking about is DB2 Tempspace filled up and caused DB2 to crash. This is a known bug according to IBM and they have a fix for V7 FP8. The thing I find very concerning is that we can't simply bring DB2 backup. Rather we are in a position to have to recover the entire Database. Our warehouse is planned to be about 60 TB with thousands of tables. I am concerned about the fact it seems many times when DB2 crashes we are in this forced recovery situation. As the database continue to grow this is going to become more and more time consuming and fraught with danger. It also puts us in a negative light with the user community and our management. It appears little DB2 has stability problems and I am becoming concerned about the answer we keep getting from IBM to do a full recovery, or that seems to be the only solution. Do other's using DB2 on AIX seem to be experiencing this problem or needing to recover the entire DB?? I am concerned we are taking a huge step backwards by taking our warehouse off the Mainframe as it seems little DB2 is where big DB2 was 15 years ago. Anyone have any thoughts they would like to share? I appreciate the opportunity to discuss this with others in the real world. Frank - ::: When replying to the list, please use 'Reply-All' and make sure ::: a copy goes to the list ([EMAIL PROTECTED]). *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] *** For more information, check http://www.db2eug.uni.cc - ::: When replying to the list, please use 'Reply-All' and make sure ::: a copy goes to the list ([EMAIL PROTECTED]). *** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] *** For more information, check http://www.db2eug.uni.cc
