Archive for May, 2010

Patch News – Oracle Patchset released

May 19th, 2010 1 comment

I just found Oracle released patchset for the following platforms:

  • Linux x86_64
  • Linux x86

See Doc ID 1088172.1 for a list of fixed problems.

Categories: Oracle in general Tags:

Oracle 11g R2: Deferred Segment Creation + imp + table with LOB column = Bug

May 7th, 2010 2 comments

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

  1. In the source database ( on 64-bit Linux):
    1. create a user named TEST1 having a default tablespace named TEST1
    2. create a small table with a CLOB in it
    3. export the schema with traditional import
    4. transfer the dump to the destination database
  2. In the destination database ( on 64-bit Linux)
    1. create a user names TESTNEU with a default tablespace TESTNEU
      NOTE: There is no tablespace TEST1 in the destination database; this is important
    2. trying to import the table… hitting a bug documented below in detail

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…

Read more…

Categories: Oracle in general Tags:

ASM Volumes on thin-provisioned SAN dirtying all blocks?

May 4th, 2010 No comments

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

Read more…

Categories: Oracle in general Tags: