Re: CONFESSION TIME.

nsouto_at_optushome.com.au.nospam (Nuno Souto) wrote in message
> the bug. it totally ignores that little bit of data around the 4Gb
> boundary. and loses track of addresses, pointers, etc.
> Nothing to do with NTFS, AFAIK. Same happens with Unix. 32-bit
> thing.

That's good to know. So, now it's clear: Never shrink really big datafile, if you do not have a spare time for recovery.

> last thing you need now is flames.

I respectfully disagree, flames can be very helplful for him. If their datacenter catches the flames, then nobody would take care about some f*cking 11GB datafile and unavailable database. :-)

> >Windows NT4 sp6a
> Surprising. I thought this problem was restricted to nix.

Microsoft already said that they're catching on Unixes. :-)

> >OEM 2.2
> that could be part of the problem, but I don't know enough of its
> operation in NT to comment.

Don't think so. I think that OEM is just a clicking interface to SQL statements. Every action from OEM should be just ordinary SQL statement for database. So I think that he would have the same problem even with:
alter database datafile <blah> resize .... typed via svrmgrl.

I hope that recovery will be succesful and users patient and tactful.

--
_________________________________________

Dusan Bolek, Ing.
Oracle team leader

Note: pagesflames_at_usa.net has been cancelled due to changes (maybe we
can call it an overture to bankruptcy) on that server. I'm still using
this email to prevent SPAM. Maybe one day I will change it and have a
proper mail even for news, but right now I can be reached by this
email.