I just found Oracle released 10.2.0.5.0 patchset for the following platforms:
See Doc ID 1088172.1 for a list of fixed problems.
This is a short posting about an error i found today.
This errors prevents the import of tables with lob columns when using traditional import, deferred segment creation and an altered tablespace name.
For this i created a test case in which we
Note: While blogging this for a fried i was in hurry; i will rewrite some paragraphs with evening… but the problem should become clear while reading…
Some time ago i´ve seen a discussion on OTN about ASM and thin provisioned volumes.
Hi there, sorry for the x-post from database-general but it was suggested that I do so. Anyhow, we've got 11g (11.1.0.7 with the 6851110 ASM patch recently applied) running on OEL 5 x86_64, with ASM connected to a raw, thin-provisioned ISCSI volume partitioned for +DATA and +FRA, and in every case where we do so, the SAN device reports within a few weeks that the whole volume has been allocated even though the DB (configured with autoextend on) is only holding about one tenth of the amount of available space on the device. What this means in systems terms is that somehow ASM is marking writes to nearly every block on the drive if only momentarily.
In the original thread, there was speculation that a process of indexing AUs has led to the dirtying of the whole volume, but this would make more sense if the whole disk had been allocated immediately rather than over the course of a few weeks. My question is: what else could account for this behavior, and what steps can I take to help ensure that ASM behaves correctly in a thin-provisioned volume? (by "correctly" I mean writes contiguous blocks of data and doesn't dirty the whole thing)
Yesterday i had some spare time available to dig a little bit deeper. I had a Windows-based system at hand and performed some smaller tests.