Neil Truby wrote:

> 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?

The ability to address much bigger databases and not to have to install an
LVM on those primitive OSes that don't come with one.

--
"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

Rich Campbell wrote:

> You will not uncover stability problems by just using the software in a
> dev/test environment with limited usage.
>
> What kind of application do you support?

Oh dear. I sense the arrival of a man armed only with a knife at a gunfight.
)

--
"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

Rich Campbell observed:
> But stability counts the MOST

I would agree with you except for profitability. We resell IDS as
part of our app, and we cannot sell supported licenses after IBM stops
selling licenses.

> and 9.40 is NOT stable yet.

That remains to be proven. I am not arguing, Rich, but I have
productions systems that crash on 7.31 with no explanation, too.

My point about interim releases was that I have seldom seen any
release prior to UC3 which was truly ready for production. The first
commercial release is for finding the bugs that slipped past the beta
testers, the second is for patching the show-stopper bugs that
prevented further testing, and only the third is really ready for
prime time.

This has been my experience with Informix. When 7.31.UC1 came out, we
referred to it as the Holy Grail release. Within days of general
availability, support was warning people of security holes and they
needed to wait for 7.31.UC2. Oddly enough, releases 7.31.UD1 all the
way through 7.31.UD3 had significant bugs that made me wonder how they
had gotten past QA. 7.31.UD4, on which our customers currently
reside, has bugs that are not fixed until UD7, and UD5 has one that is
a show stopper for us (though it might not be for everyone).

> Support also says that 30 bugs are being fixed per week!!

How does that compare to 7.31? If there are fewer, is that because
the bugs are only being fixed in the 9 family?

> Features are nice, stability is paramount...

I will not disagree that stability is more important than features.
That does not keep me from wanting the features.

In the perfect world, features and stability would come automatically.

> Oh, and by the way end-of-life (support) for 7.31 and 9.40 happens to be the
> same date...

But support contracts will not be sold after April 2005. That is my
deadline.

> What kind of application do you support?

We resell a database which is 24*7, mixed OLTP/DSS functionality, 300
installations. Average number of users per installation expected to
increase by factor of ten in the next two years.

Meanwhile, the Clown obnoxioed:
> Oh dear. I sense the arrival of a man armed only with a knife at a gunfight.

Now, now, I have never shot a man for abbreviating my name
unnecessarily. Rich and I may have a difference of opinion, but he
need not be strung up for reporting on a negative experience.
Besides, at this point, I want to hear about problems people are
experiencing with We are not blindly supportive of IBM and the
Informix product line around here.

Are we?

As for Neil's question: "Can anyone (apart from Jonathan Lefler!)
please explain to me why the removal of the 2GByte chunk limit is so
great?"

First, there is the geek part of me that has just wanted to see this
limit go away for a long time.

Second, all the utilities which fail when their output files exceed
2GB make my life miserable.

The larger databases are nice, theoretically, by my databases are not
close to exceeding the max available in 7.31, yet.

But the final reason, for me, is the most important: I am sick and
tired of explaining why my customers have to break their huge drives
into small pieces, and then having to argue (politely, of course) with
their IS departments. It is an administration headache, especially on
Solaris where you can only get 8 slices per drive without an expensive
LVM, and the IS departments always complain.

Sincerely,

Christopher Coleman

Database Analyst
Pharmacy Division
Mediware Information Systems, Inc.

"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.

Rich Campbell wrote:

> Features are nice, stability is paramount when supporting an application
> with 1000 users and 24 x 7 availability requirements for a business
> critical application. Tell me how I am wrong?

I'm not saying you are wrong... But with no details your post becomes FUD.
As I said I know of success cases.

> What kind of application do you support?

Some which cause 23M session in 61 days of uptime... still at 7.31.
Possibily changing some smaller instances to 9.40 in the near future.

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.c om...
> "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.

>
> > 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.

There are two reasons to group IO on a chunk basis. 1) is the old
business of trying to take advantage of the physical placement. 2) is
to be able to buddy-bunch multiple small IO blocks into a single
larger IO request. Even with SAN environments, the second reason is
still valid.

By sorting the IO writes during a checkpoint, we are able to use large
buffer writes, and thus reduce the total number of physical writes
that are required.

"Rich Campbell" <rich.campbell@att.com> wrote in message news:<bpivsu$bs636@kcweb01.netnews.att.com>...
> Chris,
>
> Don't get me wrong, being a long time Informix user and supporter, the
> features in 9.40 are rich.
>
> But stability counts the MOST, and 9.40 is NOT stable yet. We have had
> three instance crashes when running a
> real production "load test". Support has yet to explain them. Support
> also says that 30 bugs are being fixed per week!!
>
Rich,

We are not fixing 30 bugs a week. We are not getting anywhere that
level of bug inflow. I don't know who in tech support told you that.
The actual number is more like < 5.

We get an email for every bug that is integreated into the product. I
may be getting a whole bunch of emails, but I know that I'm not
getting 30 emails a week indicating bug fixes. ;-)