Re: 9.40 buggy!

"Neil Truby" <neil.truby@ardenta.com> wrote in message news:<bpisoe$1olu8d$1@ID-162943.news.uni-berlin.de>... > Can anyone (apart from Jonathan Lefler!) please explain to me why the > removal of the 2GByte chunk limit is so great? > I agree that the limit is a pain in the arse for database administrators. > But, apart from fewer chunks to keep a track of, what other step-changes > does it usher into our lives? > > -- > Neil Truby t:01932 724027 > Director m:07798 811708 > Ardenta Limited e:neil.truby@ardenta.com > 1) We have some key customers that were running into the 4TB limit 2) It allows customers to use large disk environments without having to use a LVM 3) IO is scheduled on a chunk basis. There is loss of scheduling optimization if systems are not configured so that there is a mapping between the logical device and the physical device. 4) We were constantly getting hammered by customers because we could not support sizes beyond the 2GB limit.

Madison Pruet wrote: > 4) We were constantly getting hammered by customers because we could > not support sizes beyond the 2GB limit. Can I point my hammer to the people who has been holding the release of table restore from archive? ;) I've tried "turbo" archecker from John Miller, but with little or no success... It either hist some limitations or apparently works but gave me null rows :( Just a bit of finger pointing ;) Regards.

Madison Pruet wrote: > > "Neil Truby" <neil.truby@ardenta.com> wrote in message news:<bpisoe$1olu8d$1@ID-162943.news.uni-berlin.de>... > > Can anyone (apart from Jonathan Lefler!) please explain to me why the > > removal of the 2GByte chunk limit is so great? > > I agree that the limit is a pain in the arse for database administrators. > > But, apart from fewer chunks to keep a track of, what other step-changes > > does it usher into our lives? > > > > -- > > Neil Truby t:01932 724027 > > Director m:07798 811708 > > Ardenta Limited e:neil.truby@ardenta.com > > > > 1) We have some key customers that were running into the 4TB limit > 2) It allows customers to use large disk environments without having > to use a LVM > 3) IO is scheduled on a chunk basis. There is loss of scheduling > optimization if systems are not configured so that there is a mapping > between the logical device and the physical device. > 4) We were constantly getting hammered by customers because we could > not support sizes beyond the 2GB limit. hmm this needs a bit more detail. #2 seems to contradict #3 Nowadays large disk environment means storage consolidation, that implies SAN, those deliver RAID5 LUNs upto a size of (<huuuge>) via concatenation smallish Metadrives or LVOL or .... else you get out many tiny pieces of your SAN box upto the limit of LUNs (which is somewhat smallish, but high enough to make it possible to sell a LVM to you) Therefore you need a LVM anyway to make something useful out of those large piles of crap You lose each and every piece of control about what is where, thanks to striping where you cannot change the stripe size or some similar silly 'feature' of you SAN box, depending on the vendor. Therefore #3 cannot easily be fullfilled anymore ..... Also read 9.40 docs: it recommends putting all space of one disk (or one LUN) into 1 chunk, which is utter crap. The page header contention problem, though, will only be fixed in UC4, at least we have got this final reply on our support case when we lost the ability to use oncheck -pe to see what is where in our singleton test 4GB chunk. Correct me, if I have missed something or if I am just too old to adapt to latest KiLlAFeAtUrEs quickly enough. dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe

"Madison Pruet" <mpruet@us.ibm.com> wrote in message news:60188682.0311210841.1bd61ee5@posting.google.com... > "Neil Truby" <neil.truby@ardenta.com> wrote in message news:<bpisoe$1olu8d$1@ID-162943.news.uni-berlin.de>... > > Can anyone (apart from Jonathan Lefler!) please explain to me why the > > removal of the 2GByte chunk limit is so great? > > I agree that the limit is a pain in the arse for database administrators. > > But, apart from fewer chunks to keep a track of, what other step-changes > > does it usher into our lives? > > > > -- > > Neil Truby t:01932 724027 > > Director m:07798 811708 > > Ardenta Limited e:neil.truby@ardenta.com > 3) IO is scheduled on a chunk basis. There is loss of scheduling > optimization if systems are not configured so that there is a mapping > between the logical device and the physical device. Er .... er ... am I alone in working with particularly technologically advanced sites? Almost every customer I have now is using some sort of SAN. One of the characteristics of these SANs is that, such is the level of indirection between logical devices and physical disks, it is not viable to make *any* inferences about the physical location of your data.