Partitioned tables and IOT

Hi All,
We had a database using IOT but now because of the performance reasons
we want to elimnate IOT table and using the Parititioned Tables.
Have you ever using the partitioned tables for ORACLE with your database?
If you have done that please share your experiences or refer me some
documents related to Partitioned tables for ORACLE to make my job more
easier.
Thanks in advance,
JP

Hi,
You will get good information from this Oracle site,
http://www.oracle.com/technology/documentation/index.html.
Thanks

Similar Messages

Create a GPT partition table and format with a large volume (solved)

Hello,
I'm having trouble creating a GPT partition table for a large volume (~6T). It is a RAID 5 (hardware) with 3 hard disk drives having a size of 3T each (thus the resulting 6T volume).
I tried creating a GPT partition table with gdisk but it just fails at creating it, stopping here (I've let it run for like 3 hours...):
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/md126.
I also tried with parted but I get the same result. Out of luck, I created a GPT partition table from Windows 7 and 2 NTFS partitions (15G and the rest of space for the other) and it worked just fine. I then tried to format the 15G partition as ext4 but, as for gdisk, mkfs.ext4 will just never stop.
Some information:
fdisk -l
Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xd9a6c0f5
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 104861695 52429824 83 Linux
/dev/sda2 104861696 466567167 180852736 83 Linux
/dev/sda3 466567168 500117503 16775168 82 Linux swap / Solaris
Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdd1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
Disk /dev/sde: 320.1 GB, 320072933376 bytes, 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x5ffb31fc
Device Boot Start End Blocks Id System
/dev/sde1 * 2048 625139711 312568832 7 HPFS/NTFS/exFAT
Disk /dev/md126: 6001.1 GB, 6001143054336 bytes, 11720982528 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 65536 bytes / 131072 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/md126p1 1 4294967295 2147483647+ ee GPT
Partition 1 does not start on physical sector boundary.
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
gdisk -l on my RAID volume (/dev/md126):
GPT fdisk (gdisk) version 0.8.7
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/md126: 11720982528 sectors, 5.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8E7D03F1-8C3A-4FE6-B7BA-502D168E87D1
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 11720982494
Partitions will be aligned on 8-sector boundaries
Total free space is 6077 sectors (3.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 34 262177 128.0 MiB 0C01 Microsoft reserved part
2 264192 33032191 15.6 GiB 0700 Basic data partition
3 33032192 11720978431 5.4 TiB 0700 Basic data partition
To make things clear: sda is an SSD on which Archlinux has been freshly installed (sda1 for root, sda2 for home, sda3 for swap), sde is a hard disk drive having Windows 7 installed on it. My goal with the 15G partition is to format it so I can mount /var on the HDD rather than on the SSD. The large volume will be for storage.
So if anyone has any suggestion that would help me out with this, I'd be glad to read.
Cheers
Last edited by Rolinh (2013-08-16 11:16:21)

Well, I finally decided to use a software RAID as I will not share this partition with Windows anyway and it seems a better choice than the fake RAID.
Therefore, I used the mdadm utility to create my RAID 5:
# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
# mkfs.ext4 -v -m .1 -b 4096 -E stride=32,stripe-width=64 /dev/md0
It works like a charm.

[SOLVED] UEFI system booting from MBR partition table and GRUB legacy

I'm trying to understand once and for all the process by which Arch can be booted from a system with UEFI firmware and an MBR partition table. Some of the information on the wiki seems conflictual / non-nonsensical at times. Apologies in advance if this has been answered time and time again, but I did search around and all I found was fixes to get Arch to boot rather than comprehensive explanations of the boot process.
Now, the way I would imagine it works is that it's just completely identical to the way it would work with a BIOS firmware. The UEFI firmware detects an MBR partitioning scheme (or is configured to know it's an MBR partitioning scheme), activates some "legacy" mode and executes the MBR boot code, just like a BIOS firmware would.
The wiki however, says different. From the Macbook article: "Do not install GRUB onto /dev/sda !!! Doing so is likely to lead to an unstable post-environment."?
So what is there in the MBR boot sector? Nothing?
How does the firmware know what to boot if there's no 0xEF BIOS boot partition and no Grub stage 1 in the MBR boot sector?
Also, how does installing Grub stage 1 to a partition work? Does it have to be at the beginning of the partition? Wouldn't that overwrite some existing data?
I'm especially puzzled since many guides to installing Vista on a macbook recommend simply formatting as MBR, and installing as normal, which I suppose entails having the Windows installation process write its boot code to the MBR, ie the equivalent of installing grub stage 1 to /dev/sda rather than to the /boot partition, as the Macbook article suggests.
Any input is appreciated.
P.S. I realize it's probably simpler, if I just want to dual boot Windows and Arch, to install Windows 7 in UEFI-GPT mode, let it create the EFI System Partition, and then install GRUB 2 to that partition, but I'm still curious about the UEFI-MBR boot process.
Last edited by padavoine (2012-06-06 09:35:10)

padavoine wrote:
CSM in UEFI firmwares do the exact same job as normal BIOS firmware.
So it's something specific to the Mac that it's able to boot from a partition's VBR while ignoring the MBR?
The reason that warning is given is because grub-legacy modifies more than just the MBR boot code region. It can overwrite some parts of GPT header.
Not true, the instruction is given in the context of an MBR format, not in the context of a GPT format, so there's nothing to overwrite and Stage 1.5 should be safely embeddable in the post-MBR gap.
In BIOS boot (normal case in non-UEFI firmwares or CSM in UEFI firmwares) does not read the partitition table (atleast it is supposed to be dumb in this regard), it simply launches whatever boot code exists in the 1st 440-byte of the MBR region.
So again, you're saying it's specific to the Mac UEFI that it lets you choose a partition whose VBR to load, regardless of what's in the MBR?
I haven't used Macs so I can't comment on Mac firmware behaviour. But normal BIOS firmwares (legacy and CSM) launch only the MBR boot code and not the partition boot code. We need some chainload capable boot manager in the MBR to launch the partition VBR.
grub-legacy does not know anything about GPT. So when you install grub-legacy to /dev/sda, it install the MBR boot code (stage1) and stage 1.5 code to the (supposed) post MBR gap. Since there is no actual post MBR gap in GPT (which has been taken over by the header and partition table), grub-legacy does not check for GPT and it assumes the post MBR gap actually exists which is invalid in case of GPT. grub-legacy embeds the stage 1.5 code in GPT header and table region (which grub assumes to be unused post MBR gap) and thus corrupts it.
0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.
That's precisely my point: with neither proper executable code in the MBR (since grub was installed to a partition, not to the MBR) nor a UEFI system partition, what does the firmware default to, and how does it know what partition to boot from?
In that case it might fallback to UEFI Shell (if it exists) or give an error similar to the case where BIOS does not find any bootable code in 440-byte MBR region.
So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.
I know what Bootcamp does, and that's not what I was referring to. I was referring to standalone Vista installs. I wasn't puzzled at the fact that they were using MBR, I was puzzled at the fact that contrary to the recommendations for the standalone Arch install on the wiki (with MBR partitioning, not GPT), they didn't do anything to try and prevent Windows from writing to the MBR.
You can't prevent Windows from overwriting the MBR region. You have to re-install the bootloader (grub2/syslinux etc.) after installing Windows. That is the reason why it is recommended to install Windows first and linux later.
Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD.
I haven't done it since the only UEFI system I own has no DVD drive, but I was under the impression that it was simply a matter of choosing DVD UEFI boot in the firmware's boot menu.
format the USB as FAT32 and extract the iso to it. That it.
No, thats not it, precisely, it doesn't work out of the box with a standard Windows install USB, you need to fiddle around:
2.3 Extract bootmgfw.efi from [WINDOWS_x86_64_ISO]/sources/install.wim => [INSTALL.WIM]/1/Windows/Boot/EFI/bootmgfw.efi (using 7-zip aka p7zip for both the files), or copy it from C:\Windows\Boot\EFI\bootmgfw.efi from a working Windows x86_64 installation.
2.4 Copy the extracted bootmgfw.efi file to [MOUNTPOINT]/efi/microsoft/boot/bootmgfw.efi .
Most of the Windows isos already have /EFI/BOOT/BOOTX64.EFI file, so no need to extract the bootmgfw.efi file.
There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware.
There has to be a difference, at least in the Mac firmware (sorry, I keep switching), since legacy firmware, AFAIK, cannot chainload a bootloader in a partition's VBR without there being some sort of "stage1" code in the MBR.
No idea about Mac EFI. Apple made a spagetti out of UEFI Spec. To actually understand how Mac firmwares work, read the blog posts by Matthew Garrett of Redhat, about his efforts in getting Fedora to boot in Macs.

How to partition tables and indexes in this scenario?

So our situation is pretty simple. We have 3 tables.
A, B and C
the model is A->>B->>C
Currently A, B and C are range partitioned on a key created_date however it's typical that only C is every qualfied with created date. There is a foreign key from B -> A and C -> B
we have many queries where the data is identified by state that is indexed currently non partitioned on columns in A ... there are also indexes on the foreign keys that get from C -> B -> A. Again these are non partitioned indexes at this time.
It is typical that we qualify A on either account or user or both. There are indexes (non partitioned) on these
We have a problem now because many of the queries use leading wildcards ie. account like '%ACCOUNT' etc. This often results in large full table scans. Our solution has been to remove the leading wildcard but this isn't always possible.
We are wondering how we can benefit from partitioning and or sub partitioning table A. since it's partitioned on created_date but rarely qualify by that.
We are also wondering where and how we can benefit from either global partitioned index or local partitioned indexes on tables A. We suspect that the index on the foreign key from C to B could be a local partitioned index.
I am also wondering what impact pushing the state from A that's used to qualify A down to C would have any advantage.
C is the table that currently we qualify with the partition key so I figure if you also pushed down the state from A that's used to qualify the set of C's we want based on the set of B's we want based on the set of A thru qualfying on columns within A.
If we push down some of those values to C and simply use C when filtering I'm wondering what the plans will look like compared to having to work all the way up from the bottom to the top before it begins qualifying A.
Edited by: steffi on Jan 14, 2011 11:36 PM

We are wondering how we can benefit from partitioning and or sub partitioning table A. since it's partitioned on >created_date but rarely qualify by that. Very good question. Why did you partition on it? You will never have INSERTS on these partitions, but maybe deletes and updates? The only advantage (I can think of) would be to set these partitions in a read only tablespace to ease backup... but that's a weired reason.
we have many queries where the data is identified by state that is indexed currently non partitioned on columns in >A ... there are also indexes on the foreign keys that get from C -> B -> A. Again these are non partitioned indexes at >this time.Of course. Why should they be partitioned by Create_date?
It is typical that we qualify A on either account or user or both. There are indexes (non partitioned) on these
We have a problem now because many of the queries use leading wildcards ie. account like '%ACCOUNT' etc. This >often results in large full table scans. Our solution has been to remove the leading wildcard but this isn't always possible.I would suspect full index scan. Isn't it?
We are also wondering where and how we can benefit from either global partitioned index or local partitioned >indexes on tables A. We suspect that the index on the foreign key from C to B could be a local partitioned index.As A is not accessed by any partition, why should C and B profit? You should look to partition by the key you are using to access. But, you are looking to tune your SQLs where the access is like '%ACCOUNT' on A. Then when there is a match. ORACLE joins via your index and nested loop (right?) to B and C.
I am also wondering what impact pushing the state from A that's used to qualify A down to C would have any >advantage.Why should it. It just makes the table and indexes larger => more IO.
C is the table that currently we qualify with the partition key so I figure if you also pushed down the state from A >that's used to qualify the set of C's we want based on the set of B's we want based on the set of A thru qualfying >on columns within A.If the access from A to C would be .. AND A.CREATE_DATE =C.CREATE_DATE and c.key like '%what I want%' which does not qualifify for a FK ;-) then, as that could be resulting in a partition scan, you could "profit". But, I'm sure that's not your model.
If we push down some of those values to C and simply use C when filtering I'm wondering what the plans will look >like compared to having to work all the way up from the bottom to the top before it begins qualifying A.So you want to denormalize A,B,C and into one table? With the same access is like '%ACCOUNT' you would get a full scan on an index as before, just the objects would be larger due to redundance and harder to maintain. In the end you would have a bad and slower design.
Maybe you explain what the problem is.
Full index scan can not be avoided, but that can be made faster by e.g. parallel query, and then the join to B and C should be a "snip" if you just identify a small subset of rows in these tables.

Importing Partitioning tables, and Indexes

Hello,
during import of several partitioned tables, we had a strange problem. All non-PK indexes were imported into the partitioned tablespaces. PK indexes, did not seem to get created as local partitioned indexes. They have defaulted to a global PK in the a regular (read non-partitioned) tablespace.
Is it normal ? Do we have to add any "special" commands or text to the import scripts for partitioned indexes ?
Anyone, can you please post a reply to this, this has happened twice.
Thanks, Sreedutt

Note that this doesn't appear to be an ODBC-related question, but a question related to the Oracle import/export utility. Since there isn't an OTN forum that addresses this particular product, you're probably best served by contacting Oracle support.
Justin Cave

SQL Loader, direct path and indexes on partition tables

Hi,
I have a big partitioned table and I have two indexes on it.
When I use SQL Loader to upload data to my table with using OPTIONS (DIRECT=TRUE) UNRECOVERABLE , then it takes almost half hour to load just one record!!
When I remove OPTIONS (DIRECT=TRUE), then it takes just two seconds to upload the same one record.
Am I missing anything? Can I use direct path load on indexed partitioned tables and have reasonable load time ?
An scheduled external job loads almost 100,000 records into this table every hour and I am trying to make the sql*loader performance it as fast as possible.
Any help would be appreciated,
Alan

Hi Alan,
How big is this table and what sort of indexes are they?
An index update using SQL*Loader unrecoverable direct path load is achieved by an isolated sort followed by a nologging merge of the old index and the new mini-index into a new index segment (this according to seminar notes by Jonathan Lewis). This will conceivably take a long time for a large table / large index.
Performance improvements? Are you loading all records into a new partition?
Cheers,
Colin

Performance issues with version enable partitioned tables?

Hi all,
Are there any known performance issues with version enable partitioned tables?
Ive been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
Tanks in advance,
Vitor
Example:
     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
UPDATE STATEMENT Optimizer Mode=CHOOSE          1          249
UPDATE     SIG.SIG_QUA_IMG_LT
NESTED LOOPS SEMI          1     266     249
PARTITION RANGE ALL                                   1     9
TABLE ACCESS FULL     SIG.SIG_QUA_IMG_LT     1     259     2               1     9
VIEW     SYS.VW_NSO_1     1     7     247
NESTED LOOPS          1     739     247
NESTED LOOPS          1     677     247
NESTED LOOPS          1     412     246
NESTED LOOPS          1     114     244
INDEX RANGE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62     2
INDEX RANGE SCAN     SIG.QIM_PK     1     52     243
TABLE ACCESS BY GLOBAL INDEX ROWID     SIG.SIG_QUA_IMG_LT     1     298     2               ROWID     ROW L
INDEX RANGE SCAN     SIG.SIG_QUA_IMG_PKI$     1          1
INDEX RANGE SCAN     WMSYS.WM$NEXTVER_TABLE_NV_INDX     1     265     1
INDEX UNIQUE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62
/* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */
UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1
SET z1.nextver =
SYS.ltutil.subsversion
(z1.nextver,
SYS.ltutil.getcontainedverinrange (z1.nextver,
'SIG.SIG_QUA_IMG',
'NpCyPCX3dkOAHSuBMjGioQ==',
4574,
4575
4574
WHERE z1.ROWID IN (
(SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
t2.ROWID
FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j1,
sig.sig_qua_img_lt t1,
sig.sig_qua_img_lt t2,
wmsys.wm$nextver_table j2,
(SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j3
WHERE t1.VERSION = j1.VERSION
AND t1.ima_id = t2.ima_id
AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
AND t2.nextver != '-1'
AND t2.nextver = j2.next_vers
AND j2.VERSION = j3.VERSION))

Hello Vitor,
There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
Thank You,
Ben

Domain index on list-partitioned table?

Hi,
I have a list-partitioned table, and wanted to create a partitioned Oracle Text index on it. I keep getting an error, and am now wondering if it's possible to do. Here is my syntax:
CREATE INDEX SCHEMA1.IDX_ALL_TEXT_LOCAL ON SCHEMA1.TABLE1(ALL_TEXT)
INDEXTYPE IS CTXSYS.CONTEXT
LOCAL
(PARTITION PTN1 PARAMETERS('sync (on commit) storage ptn1'),
PARTITION PTN2 PARAMETERS('sync (on commit) storage ptn2'),
PARTITION PTN3 PARAMETERS('sync (on commit) storage ptn3'),
PARTITION PTN4 PARAMETERS('sync (on commit) storage ptn4'),
PARTITION PTN5 PARAMETERS('sync (on commit) storage ptn5'),
PARTITION PTN6 PARAMETERS('sync (on commit) storage ptn6'),
PARTITION PTN7 PARAMETERS('sync (on commit) storage ptn7'),
PARTITION PTN8 PARAMETERS('sync (on commit) storage ptn8')
PARAMETERS('section group my_group lexer new_lexer');
ERROR at line 1:
ORA-29850: invalid option for creation of domain indexes
Any advice would be much appreciated.
Thanks,
Nora

... will it spread the index across the tablespaces that are associated with each partition?No, as demonstrated below.
SCOTT@orcl_11gR2> CREATE TABLE table1
2      ( id         NUMBER(6),
3        all_text      VARCHAR2 (20)
4      )
5 PARTITION BY LIST (id)
6   (PARTITION ptn1 VALUES (2,4) TABLESPACE example,
7    PARTITION ptn2 VALUES (3,9) TABLESPACE example
8   )
9 /
Table created.
SCOTT@orcl_11gR2> INSERT ALL
2 INTO table1 VALUES (2, 'test2')
3 INTO table1 VALUES (3, 'test3')
4 INTO table1 VALUES (4, 'test4')
5 INTO table1 VALUES (9, 'test9')
6 SELECT * FROM DUAL
7 /
4 rows created.
SCOTT@orcl_11gR2> CREATE INDEX IDX_ALL_TEXT_LOCAL
2 ON TABLE1 (ALL_TEXT)
3 INDEXTYPE IS CTXSYS.CONTEXT
4 /
Index created.
SCOTT@orcl_11gR2> SELECT table_name, tablespace_name
2 FROM   user_tab_partitions
3 WHERE table_name = 'TABLE1'
4 /
TABLE_NAME                     TABLESPACE_NAME
TABLE1                         EXAMPLE
TABLE1                         EXAMPLE
2 rows selected.
SCOTT@orcl_11gR2> SELECT table_name, tablespace_name
2 FROM   user_tables
3 WHERE table_name LIKE '%IDX_ALL_TEXT_LOCAL%'
4 /
TABLE_NAME                     TABLESPACE_NAME
DR$IDX_ALL_TEXT_LOCAL$I        USERS
DR$IDX_ALL_TEXT_LOCAL$R        USERS
DR$IDX_ALL_TEXT_LOCAL$N
DR$IDX_ALL_TEXT_LOCAL$K
4 rows selected.
SCOTT@orcl_11gR2>

Deadlock issue in Oracle 10g Partitioned Tables

Hi ALL,
I am facing an issue of Deadlock while inserting data into a partitioned table.
I get an error "ORA-00600: Deadlock detected". when i see the trace files, following lines are appearing in them:
"Single resource deadlock: blocking enqueue which blocks itself".
Here is the detail of my test case:
1. I have a list-partitioned table, with partitioning defined on some business codes.
2. I have a query that merges data into partitioned table (actually compares unique keys between temporary table and partitioned table and then issue an insert if keys not matched, no update part).
3. The temporary table contains transactional data against many business codes.
3. when calling the above query from multiple (PL/SQL) sessions, i observe that when we merge data in same partition (from different sessions) than deadlock issue occurs, otherwise it is OK.
4. Note that all sessions are executed at same time. Also note that Commit is called after each session is completed. Each session contains 2-3 more queries after the mentioned merge statement.
Is there an issue with oracle merge/insert on same partition (from different sessions)? What is the locking mechanism for this particular case (partitioned tables)?
My oracle version is Oracle 10g (10.2.0.4). Kindly advice.
Thanks,
QQ.

Could you print the deadlock tree so we can see the type and mode of the locking. (Please use the 'code' tags - see FAQ at top right of screen - to showthe output in fixed font). can you list any SQL operated by this session that gets reported in the trace file.
Does the table reference itself in a foreign key.
Is this table involved in any referential integrity constraints.
Do you have a global primary key index, or a local primary key index ?
Are there any triggers on the table - if so do they contain autonomous transactions.
At present the only though that springs to mind is that the merge command has to lock the target table to do the insert/update, but it also has to lock any child table. The mode of the child lock depends on whether it has a suitable index or not, and whether the child table IS also the parent table. If you have two merges to the same partition one partition may get its locks, and the other partition may be in a state where it can't get one of the locks because it's wait for the other. (This shouldn't be a self-deadlock, though, but the scenario might be heading in the right direction for a self-deadlock).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking)

Partition Table Query taking Too Much Time

I have created partition table and Created local partition index on a column whose datatype is DATE.
Now when I Query table and use index column in the where clause It is scaning all the table (Full scan) . The quey is :
Select * From mytable
where to_char(transaction_date, 'DD-MON-YY') = '01-Aug-07';
I have to use to_char function not to_date due to Front end application problem.

Before we go too far with this, if you manually query with TO_DATE on the variable instead of TO_CHAR on the column, does the query actually use the index?
The TO_CHAR on the column will definitely stop Oracle from using any index on the column. If the query will use the index if you TO_DATE the variable, as I see it, you have three options. First, fix the application problem that won't let you use TO_DATE from the application. Second, change the application to call a function returning a ref cursor, get the date string as a parameter to the function, and do the TO_DATE in the function.
Third, you could consider creating a function-based index on TO_CHAR(transaction_date, 'dd-Mon-yy'). This would be the least desirable option, particularly if you would also be selecting records based on a range of transaction_dates, since it loses a lot of information that the optimizer could use in devising an efficient query plan. It could also change your results for a range scan.
John

CTAS using dbms_metadata.get_ddl for Partitioned table

Hi,
I would like to create a temporary table from a partitioned table using CTAS. I plan to use the following steps in a PL/SQL procedure:
1. Use dbms_metadata.get_ddl to get the script
2. Use raplace function to change the tablename to temptable
3. execute the script to get the temp table created.
SQL> create or replace procedure p1 as
2 l_clob clob;
3 str long;
4 begin
5 SELECT dbms_metadata.get_ddl('TABLE', 'FACT_TABLE','USER1') into l_clob FROM DUAL;
6 dbms_output.put_line('CLOB Length:'||dbms_lob.getlength(l_clob));
7 str:=dbms_lob.substr(l_clob,dbms_lob.getlength(l_clob),1);
8 dbms_output.put_line('DDL:'||str);
9 end;
12 /
Procedure created.
SQL> exec p1;
CLOB Length:73376
DDL:
PL/SQL procedure successfully completed.
I cannot see the DDL at all. Please help.

Thanks Adam. The following piece of code is supposed to do that. But, its failing because the dbms_lob.substr(l_clob,4000,4000*v_intIdx +1); is putting newline and therefore dbms_sql.parse
is failing.
Please advice.
create table my_metadata(stmt_no number, ddl_stmt clob);
CREATE OR REPLACE package USER1.genTempTable is
procedure getDDL;
procedure createTempTab;
end;
CREATE OR REPLACE package body USER1.genTempTable is
procedure getDDL as
Description: get a DDL from a partitioned table and change the table name
Reference: Q: How Could I Format The Output From Dbms_metadata.Get_ddl Utility? [ID 394143.1]
l_clob clob := empty_clob();
str long;
l_dummy varchar2(25);
dbms_lob does not have any replace function; the following function is a trick to do that
procedure lob_replace( p_lob in out clob, p_what in varchar2, p_with in varchar2 )as
n number;
begin
n := dbms_lob.instr( p_lob, p_what );
if ( nvl(n,0) > 0 )
then
dbms_lob.copy( p_lob,
p_lob,
dbms_lob.getlength(p_lob),
n+length(p_with),
n+length(p_what) );
dbms_lob.write( p_lob, length(p_with), n, p_with );
if ( length(p_what) > length(p_with) )
then
dbms_lob.trim( p_lob,
dbms_lob.getlength(p_lob)-(length(p_what)-length(p_with)) );
end if;
end if;
end lob_replace;
begin
DBMS_METADATA.SET_TRANSFORM_PARAM(DBMS_METADATA.SESSION_TRANSFORM,'STORAGE',false);
DBMS_METADATA.SET_TRANSFORM_PARAM(DBMS_METADATA.SESSION_TRANSFORM,'SEGMENT_ATTRIBUTES',false);
DBMS_METADATA.SET_TRANSFORM_PARAM (DBMS_METADATA.SESSION_TRANSFORM,'SQLTERMINATOR',true);
DBMS_METADATA.SET_TRANSFORM_PARAM (DBMS_METADATA.SESSION_TRANSFORM,'SEGMENT_ATTRIBUTES',false);
execute immediate 'truncate table my_metadata';
-- Get DDL
SELECT dbms_metadata.get_ddl('TABLE', 'FACT','USER1') into l_clob FROM DUAL;
-- Insert the DDL into the metadata table
insert into my_metadata values(1,l_clob);
commit;
-- Change the table name into a temporary table
select ddl_stmt into l_clob from my_metadata where stmt_no =1 for update;
lob_replace(l_clob,'"FACT"','"FACT_T"');
insert into my_metadata values(2,l_clob);
commit;
-- execute immediate l_clob; <---- Cannot be executed in 10.2.0.5; supported in 11gR2
DBMS_METADATA.SET_TRANSFORM_PARAM(DBMS_METADATA.SESSION_TRANSFORM,'DEFAULT');
end getDDL;
Procedure to create temporary table
procedure createTempTab as
v_intCur pls_integer;
v_intIdx pls_integer;
v_intNumRows pls_integer;
v_vcStmt dbms_sql.varchar2a;
l_clob clob := empty_clob();
l_str varchar2(4000);
l_length number;
l_loops number;
begin
select ddl_stmt into l_clob from my_metadata where stmt_no=2;
l_length := dbms_lob.getlength(l_clob);
l_loops := ceil(l_length/4000);
for v_intIdx in 0..l_loops loop
l_str:=dbms_lob.substr(l_clob,4000,4000*v_intIdx +1);
l_str := replace(l_str,chr(10),'');
l_str := replace(l_str,chr(13),'');
l_str := replace(l_str,chr(9),'');
v_vcStmt(v_intIdx) := l_str;
end loop;
for v_intIdx in 0..l_loops loop
dbms_output.put_line(v_vcStmt(v_intIdx));
end loop;
v_intCur := dbms_sql.open_cursor;
dbms_sql.parse(
c => v_intCur,
statement => v_vcStmt,
lb => 0,
--ub => v_intIdx,
ub => l_loops,
lfflg => true,
language_flag => dbms_sql.native);
v_intNumRows := dbms_sql.execute(v_intCur);
dbms_sql.close_cursor(v_intCur);
end createTempTab;
end;
/

Issue with updating partitioned table

Hi,
Anyone seen this bug with updating partitioned tables.
Its very esoteric - its occurs when we update a partitioned table using a join to a temp table (not non-temp table) when the join has multiple joins and you're updating the partitoned column that isn't the first column in the primary key and the table contains a bit field. We've tried changing just one of these features and the bug disappears.
We've tested this on 15.5 and 15.7 SP122 and the error occurs in both of them.
Here's the test case - it does the same operation of a partitioned table and a non-partitioned table, but the partitioned table shows and error of "Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'".
I'd be interested if anyone has seen this and has a version of Sybase without the issue.
Unfortunately when it happens on a replicated table - it takes down rep server.
CREATE TABLE #table1
    (   PK          char(8) null,
        FileDate        date,
        changed         bit
CREATE TABLE partitioned (
PK         char(8) NOT NULL,
ValidFrom     date DEFAULT current_date() NOT NULL,
ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
LOCK DATAROWS
PARTITION BY RANGE (ValidTo)
( p2014 VALUES <= ('20141231') ON [default],
p2015 VALUES <= ('20151231') ON [default],
pMAX VALUES <= (MAX) ON [default]
CREATE UNIQUE CLUSTERED INDEX pk
ON partitioned(PK, ValidFrom, ValidTo)
LOCAL INDEX
CREATE TABLE unpartitioned (
PK         char(8) NOT NULL,
ValidFrom     date DEFAULT current_date() NOT NULL,
ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
LOCK DATAROWS
CREATE UNIQUE CLUSTERED INDEX pk
ON unpartitioned(PK, ValidFrom, ValidTo)
insert partitioned
select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
insert unpartitioned
select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
insert #table1
select "ET00jPzh", "Jan 15 2015", 1
union all
select "ET00jPzh", "Jan 15 2015", 1
go
update partitioned
set    ValidTo = dateadd(dd,-1,FileDate)
from   #table1 t
inner join partitioned p on (p.PK = t.PK)
where p.ValidTo = '99991231'
and    t.changed = 1
go
update unpartitioned
set    ValidTo = dateadd(dd,-1,FileDate)
from   #table1 t
inner join unpartitioned u on (u.PK = t.PK)
where u.ValidTo = '99991231'
and    t.changed = 1
go
drop table #table1
go
drop table partitioned
drop table unpartitioned
go

wrt to replication - it is a bit unclear as not enough information has been stated to point out what happened. I also am not sure that your DBA's are accurately telling you what happened - and may have made the problem worse by not knowing themselves what to do - e.g. 'losing' the log points to fact that someone doesn't know what they should.   You can *always* disable the replication secondary truncation point and resync a standby system, so claims about 'losing' the log are a bit strange to be making.
wrt to ASE versions, I suspect if there are any differences, it may have to do with endian-ness and not the version of ASE itself.   There may be other factors.....but I would suggest the best thing would be to open a separate message/case on it.
Adaptive Server Enterprise/15.7/EBF 23010 SMP SP130 /P/X64/Windows Server/ase157sp13x/3819/64-bit/OPT/Fri Aug 22 22:28:21 2014:
-- testing with tinyint
1> use demo_db
1>
2> CREATE TABLE #table1
3>     (   PK          char(8) null,
4>         FileDate        date,
5> --        changed         bit
6> changed tinyint
7>     )
8>
9> CREATE TABLE partitioned (
10>   PK         char(8) NOT NULL,
11>   ValidFrom     date DEFAULT current_date() NOT NULL,
12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
13>   )
14>
15> LOCK DATAROWS
16>   PARTITION BY RANGE (ValidTo)
17>   ( p2014 VALUES <= ('20141231') ON [default],
18>   p2015 VALUES <= ('20151231') ON [default],
19>   pMAX VALUES <= (MAX) ON [default]
20>         )
21>
22> CREATE UNIQUE CLUSTERED INDEX pk
23>   ON partitioned(PK, ValidFrom, ValidTo)
24>   LOCAL INDEX
25>
26> CREATE TABLE unpartitioned (
27>   PK         char(8) NOT NULL,
28>   ValidFrom     date DEFAULT current_date() NOT NULL,
29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
30>   )
31> LOCK DATAROWS
32>
33> CREATE UNIQUE CLUSTERED INDEX pk
34>   ON unpartitioned(PK, ValidFrom, ValidTo)
35>
36> insert partitioned
37> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
38>
39> insert unpartitioned
40> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
41>
42> insert #table1
43> select "ET00jPzh", "Jan 15 2015", 1
44> union all
45> select "ET00jPzh", "Jan 15 2015", 1
(1 row affected)
(1 row affected)
(2 rows affected)
1>
2> update partitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join partitioned p on (p.PK = t.PK)
6> where p.ValidTo = '99991231'
7> and    t.changed = 1
Msg 2601, Level 14, State 6:
Server 'PHILLY_ASE', Line 2:
Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
Command has been aborted.
(0 rows affected)
1>
2> update unpartitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join unpartitioned u on (u.PK = t.PK)
6> where u.ValidTo = '99991231'
7> and    t.changed = 1
(1 row affected)
1>
2> drop table #table1
1>
2> drop table partitioned
3> drop table unpartitioned
-- duplicating with 'int'
1> use demo_db
1>
2> CREATE TABLE #table1
3>     (   PK          char(8) null,
4>         FileDate        date,
5> --        changed         bit
6> changed int
7>     )
8>
9> CREATE TABLE partitioned (
10>   PK         char(8) NOT NULL,
11>   ValidFrom     date DEFAULT current_date() NOT NULL,
12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
13>   )
14>
15> LOCK DATAROWS
16>   PARTITION BY RANGE (ValidTo)
17>   ( p2014 VALUES <= ('20141231') ON [default],
18>   p2015 VALUES <= ('20151231') ON [default],
19>   pMAX VALUES <= (MAX) ON [default]
20>         )
21>
22> CREATE UNIQUE CLUSTERED INDEX pk
23>   ON partitioned(PK, ValidFrom, ValidTo)
24>   LOCAL INDEX
25>
26> CREATE TABLE unpartitioned (
27>   PK         char(8) NOT NULL,
28>   ValidFrom     date DEFAULT current_date() NOT NULL,
29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
30>   )
31> LOCK DATAROWS
32>
33> CREATE UNIQUE CLUSTERED INDEX pk
34>   ON unpartitioned(PK, ValidFrom, ValidTo)
35>
36> insert partitioned
37> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
38>
39> insert unpartitioned
40> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
41>
42> insert #table1
43> select "ET00jPzh", "Jan 15 2015", 1
44> union all
45> select "ET00jPzh", "Jan 15 2015", 1
(1 row affected)
(1 row affected)
(2 rows affected)
1>
2> update partitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join partitioned p on (p.PK = t.PK)
6> where p.ValidTo = '99991231'
7> and    t.changed = 1
Msg 2601, Level 14, State 6:
Server 'PHILLY_ASE', Line 2:
Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
Command has been aborted.
(0 rows affected)
1>
2> update unpartitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join unpartitioned u on (u.PK = t.PK)
6> where u.ValidTo = '99991231'
7> and    t.changed = 1
(1 row affected)
1>
2> drop table #table1
1>
2> drop table partitioned
3> drop table unpartitioned

Deadlock issue in Partitioned Tables

Hi ALL,
I am facing an issue of Deadlock while inserting data into a partitioned table.
I get an error "ORA-00600: Deadlock detected". when i see the trace files, following lines are appearing in them:
"Single resource deadlock: blocking enqueue which blocks itself".
Here is the detail of my test case:
1. I have a list-partitioned table, with partitioning defined on some business codes.
2. I have a query that merges data into partitioned table (actually compares unique keys between temporary table and partitioned table and then issue an insert if keys not matched, no update part).
3. The temporary table contains transactional data against many business codes.
3. when calling the above query from multiple (PL/SQL) sessions, i observe that when we merge data in same partition (from different sessions) than deadlock issue occurs, otherwise it is OK.
4. Note that all sessions are executed at same time. Also note that Commit is called after each session is completed. Each session contains 2-3 more queries after the mentioned merge statement.
Is there an issue with oracle merge/insert on same partition (from different sessions)? What is the locking mechanism for this particular case (partitioned tables)?
My oracle version is Oracle 10g (10.2.0.4). Kindly advice.
Thanks,
QQ.

Oracle MERGE statements are slow as they must validate every record before insert.
If you use array processing with BULK COLLECT and FORALL with the SAVE EXCEPTIONS clause you can avoid most of the overhead. Just collect your rows in an array, issue a FORALL INSERT SAVE EXCEPTIONS and let Oracle handle whatever happens.
When Oracle is done, and it will be hundreds of times faster than what you are doing now, you can either process or ignore the records in the exceptions array.
Another solution, more efficient if you can do it, is to just to an INSERT INTO SELECT FROM using an exceptions table created with DBMS_ERRLOG.
www.psoug.org/reference/dbms_errlog.html

How to move lob segment in partitioned table

On my Oracle 11.2, I have a partitioned table wich I would like to move to another tablespace
After invoking script, there's still unmoved lob segment withing table
CREATE TABLE BONGO.AAA_3
ID       NUMBER,
DATUM    DATE,
OBJEKAT BLOB
TABLESPACE BONGODATA_HUGE
PCTUSED    40
PCTFREE    10
INITRANS   1
MAXTRANS   255
LOGGING
PARTITION BY RANGE (DATUM)
PARTITION P_MAXVALUE VALUES LESS THAN (MAXVALUE)
    LOGGING
    NOCOMPRESS
    TABLESPACE BONGODATA_HUGE
LOB (OBJEKAT) STORE AS
        (   TABLESPACE BONGODATA
          ENABLE        STORAGE IN ROW
          CHUNK       8192
          RETENTION
          NOCACHE
          STORAGE    (
                      INITIAL          64K
                      NEXT             1M
                      MINEXTENTS       1
                      MAXEXTENTS       UNLIMITED
                      PCTINCREASE      0
                      FREELISTS        1
                      FREELIST GROUPS 1
                      BUFFER_POOL      DEFAULT
    PCTUSED    40
    PCTFREE    10
    INITRANS   1
    MAXTRANS   255
    STORAGE    (
                INITIAL          64K
                NEXT             1M
                MINEXTENTS       1
                MAXEXTENTS       UNLIMITED
                FREELISTS        1
                FREELIST GROUPS 1
                BUFFER_POOL      DEFAULT
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;how to move this lob segment in partitioned table?
or, is there some package for data move within tablespaces?
regards

tnx...
now, I have another problem..
I have a nested table within partitioned table, and I'm trying to move it to another tablespace.
I tried to move child table (of nested type colum), but I didn't succedeed...

How to find the partition column in a partitioned table

Hi,
I have a partition table and I need to find out what column was used to partition the table. Range partition.
Thanks,
Maria Sanchez

select *
from dba_part_key_columns

Partitioned tables and IOT

Similar Messages

Maybe you are looking for