Range Partition Problem

I have a table on a Oracle 10g R2 Database that has id numbers, the table was divided on two tablespaces. Four partitions were made on the first tablespace, e.g. id numbers 10000, 20000, 30000, 40000 while the other tablespace has three partitions 50000, 60000, 70000. There is no space left in this tablespace to create another partition of 80000. The problem is that when users insert into this table, they get the following error, ORA-14400 inserted partition key does not map to any partition. While on em console I can see the following message, 'This Table Contains Columns That Are In Partially Dropped State. No Operations Are Premitted Until The Drop Operations Completes'. So do I need to assign another tablespace or increase the size of that tablespace? If yes, then which is better in terms of preformance and why?
Thank you
Adith

Do you have a maxvalue partition? For example is there a partition that says 70000->maxvalue? If there isn't and because you don't have space then you need to split the 70000 partition and have a maxvalue partition, but if you don't have space then how are you going to insert the data? If you split the partition then you will need to rebuild global indexes if any or create new local ones. On the other hand why don't you just make the tablespace bigger and add a 70000->80000 partition? Whether you want to create a new tablespace is up to you and a question of why were the two tablespaces created in the first place. Don't know what the 2nd error is from apart from it sounds like a column was dropped on the table.It is dangerous to do operations like that (table DDL) while transactions are still occurring. The other one to watch for is changing or adding a column with a default value which causes every row to be updated in the table and takes out an exclusive lock.

Similar Messages

Problem with a 2 columns Range Partitioning for a indexed organized table

have an indexed organized table with a 2 column PK. the first field (datum) is a date field the second field (installatieid) is a number(2) field.
Every minute a 7 records are inserted (installatieid 0-6).
I like to partition this table with one partition per year per installatieid.
I tried to do it with:
partition by range(datum,installatieid)
(partition P_2004_0 values less than (to_date('2004-01,'yyyy-mm'),1)
,partition P_2004_6 values less than (to_date('2004-01','yyyy-mm'),7)
partition P_2005_0 values less than (to_date('2005-01','yyyy-mm'),1)
,partition P_2005_6 values less than (to_date('2005-01','yyyy-mm'),7)
but now only the P_2004_0 and P_2005_0 are filled.
I thought about to combine a range partition on datum with a list subpartition on installatieid, but I read this is not allowed with an index organized table.
How can I solve this problem.

partition by range(datum,installatieid)
(partition P_2004_0 values less than
(to_date('2004-01,'yyyy-mm'))
,partition P_2004_6 values less than
(to_date('2004-07','yyyy-mm'))
partition P_2005_0 values less than
(to_date('2005-01','yyyy-mm'))
,partition P_2005_6 values less than
(to_date('2005-07','yyyy-mm'))
? Sorry haven't got time to test it this morning ;0)

Problem exchanging partitions using range partitioning

I have a range-partitioned table. Here's a cut down version....
CREATE TABLE MY_TABLE
   (     VALUE           NUMBER,
     PARTITION_KEY      NUMBER
PARTITION BY RANGE ("PARTITION_KEY")
(PARTITION "P1" VALUES LESS THAN (2),
PARTITION "P2" VALUES LESS THAN (3),
PARTITION "P3" VALUES LESS THAN (4),
PARTITION "P4" VALUES LESS THAN (5),
PARTITION "P5" VALUES LESS THAN (6),
PARTITION "P6" VALUES LESS THAN (7),
PARTITION "P7" VALUES LESS THAN (8));For the process I'm working on, I want to be able to:
- create a table as a copy of one of the partitions
- do some processing on that table
- exchange the updated table back into the partitioned table
I can achieve this as follows....
CREATE TABLE MY_TABLE_COPY_P7 AS (SELECT * FROM MY_TABLE WHERE PARTITION_KEY = 7);
... do processing ...
ALTER TABLE MY_TABLE DROP PARTITION P7;
ALTER TABLE MY_TABLE ADD PARTITION P7 VALUES LESS THAN (8);
ALTER TABLE MY_TABLE EXCHANGE PARTITION P7 WITH TABLE MY_TABLE_COPY INCLUDING INDEXES;However, this only works if the partition I'm adding back in is the highest partition.
If I try do take out one of the middle partitions, then add it back I get an error:
SQL] ALTER TABLE MY_TABLE ADD PARTITION P5 VALUES LESS THAN (6);
ALTER TABLE MY_TABLE ADD PARTITION P5 VALUES LESS THAN (6)
ERROR at line 1:
ORA-14074: partition bound must collate higher than that of the last partitionAny ideas on how I can exchange one of the middle partitions with having to first drop the higher ones?
Btw, I have to use range partitioning as we're using spatial, which only supports range partitioning.
Cheers,

Actually, you can do the exchange partition thing with 8i and over. After creating my_table from your script, I did:
SQL> INSERT INTO my_table VALUES (1,7.5);
1 row created.
SQL> INSERT INTO my_table VALUES (2, 7.2);
1 row created.
SQL> INSERT INTO my_table VALUES (3,7.7);
1 row created.
SQL> CREATE TABLE my_tab_tmp AS
2 SELECT * FROM my_table
3 WHERE 1=2;
Table created.
SQL> ALTER TABLE my_table EXCHANGE PARTITION P7 WITH TABLE my_tab_tmp;
Table altered.
SQL> SELECT * FROM my_tab_tmp;
     VALUE PARTITION_KEY
         1           7.5
         2           7.2
         3           7.7
SQL> SELECT * FROM my_table;
no rows selected
SQL> UPDATE my_tab_tmp
2 set value = value * 20;
3 rows updated.
SQL> COMMIT;
Commit complete.
SQL> ALTER TABLE my_table EXCHANGE PARTITION P7 WITH TABLE my_tab_tmp;
Table altered.
SQL> SELECT * FROM my_tab_tmp;
no rows selected
SQL> SELECT * FROM my_table;
     VALUE PARTITION_KEY
        20           7.5
        40           7.2
        60           7.7You will, of course, need to re-build any global indexes on my_table.
When you first create my_tab_tmp, you should also create indexes to match any local indexes on the partitions, then do the exchange partition using the INCLUDING INDEXES clause. You could also skip creating the indexes and then re-create them after exchanging the updated table with the partition.
Note that none of this will work if you are changing values of partition_key so thatthey fall out of the range for the partition.
HTH
John

Range partitioning does not work the way I thought it would

I have a table that is range partitioned by number.
The number represents a date field of the form: YYYYMMDDHH24
However, there are extra values on the end of the field that represent an exact datestamp so a record looks like
20071102100000001
What I found in my tests is that if I have a partition based on range based on the following:
values less than (2007110210)
Any records inserted with a length greater than what is above automatically go to the future partition. It does not make sense that I would have to add another column and then do a substr on this field for just the first 10 characters to get them to go to the correct partition.
???? I am at a bit of a loss.

Hi
If you a column storing a timestamp you should use the timestamp or date datatype, not something else!!! Not only it makes not sense but you will have a lot of problems with that. To name only two: not consistent data and misleading the query optimizer.
As you defined, since 20071102100000001 is greater than 2007110210 (i.e. not less then), I don't see why do you expect something else.
HTH
Chris

Best approach to do Range partitioning on Huge tables.

Hi All,
I am working on 11gR2 oracle 3node RAC database. below are the db details.
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
in my environment we have 10 big transaction (10 billion rows) tables and it is growing bigger and bigger. Now the management is planning to do a range partition based on created_dt partition key column.
We tested this partitioning startegy with few million record in other environment with below steps.
1. CREATE TABLE TRANSACTION_N
PARTITION BY RANGE ("CREATED_DT")
( PARTITION DATA1 VALUES LESS THAN (TO_DATE(' 2012-08-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART1,
PARTITIONDATA2 VALUES LESS THAN (TO_DATE(' 2012-09-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART2,
PARTITION DATA3 VALUES LESS THAN (TO_DATE(' 2012-10-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART3
as (select * from TRANSACTION where 1=2);
2. exchange partion for data move to new partition table from old one.
ALTER TABLE TRANSACTION_N
EXCHANGE PARTITION DATA1
WITH TABLE TRANSACTION
WITHOUT VALIDATION;
3. create required indexes (took almost 3.5 hrs with parallel 16).
4. Rename the table names and drop the old tables.
this took around 8 hrs for one table which has 70 millions of records, then for billions of records it will take more than 8 hrs. But the problem is we get only 2 to 3 hrs of down time in production to implement these change for all tables.
Can you please suggest the best approach i can do, to copy that much big data from existing table to the newly created partitioned table and create required indexes.
Thanks,
Hari

>
in my environment we have 10 big transaction (10 billion rows) tables and it is growing bigger and bigger. Now the management is planning to do a range partition based on created_dt partition key column.
We tested this partitioning startegy with few million record in other environment with below steps.
1. CREATE TABLE TRANSACTION_N
PARTITION BY RANGE ("CREATED_DT")
( PARTITION DATA1 VALUES LESS THAN (TO_DATE(' 2012-08-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART1,
PARTITIONDATA2 VALUES LESS THAN (TO_DATE(' 2012-09-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART2,
PARTITION DATA3 VALUES LESS THAN (TO_DATE(' 2012-10-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART3
as (select * from TRANSACTION where 1=2);
2. exchange partion for data move to new partition table from old one.
ALTER TABLE TRANSACTION_N
EXCHANGE PARTITION DATA1
WITH TABLE TRANSACTION
WITHOUT VALIDATION;
3. create required indexes (took almost 3.5 hrs with parallel 16).
4. Rename the table names and drop the old tables.
this took around 8 hrs for one table which has 70 millions of records, then for billions of records it will take more than 8 hrs. But the problem is we get only 2 to 3 hrs of down time in production to implement these change for all tables.
Can you please suggest the best approach i can do, to copy that much big data from existing table to the newly created partitioned table and create required indexes.
>
Sorry to tell you but that test and partitioning strategy is essentially useless and won't work for you entire table anyway. One reasone is that if you use the WITHOUT VALIDATION clause you must ensure that the data being exchanged actually belongs to the partition you are putting it in. If it doesn't you won't be able to reenable or rebuild any primary key or unique constraints that exist on the table.
See Exchanging Partitions in the VLDB and Partitioning doc
http://docs.oracle.com/cd/E18283_01/server.112/e16541/part_admin002.htm#i1107555
>
When you specify WITHOUT VALIDATION for the exchange partition operation, this is normally a fast operation because it involves only data dictionary updates. However, if the table or partitioned table involved in the exchange operation has a primary key or unique constraint enabled, then the exchange operation is performed as if WITH VALIDATION were specified to maintain the integrity of the constraints.
If you specify WITHOUT VALIDATION, then you must ensure that the data to be exchanged belongs in the partition you exchange.
>
Comments below are limited to working with ONE table only.
ISSUE #1 - ALL data will have to be moved regardless of the approach used. This should be obvious since your current data is all in one segment but each partition of a partitioned table requires its own segment. So the nut of partitioning is splitting the existing data into multiple segments almost as if you were splitting it up and inserting it into multiple tables, one table for each partition.
ISSUE#2 - You likely cannot move that much data in the 2 to 3 hours window that you have available for down time even if all you had to do was copy the existing datafiles.
ISSUE#3 - Even if you can avoid issue #2 you likely cannot rebuild ALL of the required indexes in whatever remains of the outage windows after moving the data itself.
ISSUE#4 - Unless you have conducted full volume performance testing in another environment prior to doing this in production you are taking on a tremendous amount of risk.
ISSUE#5 - Unless you have fully documented the current, actual execution plans for your most critical queries in your existing system you will have great difficulty overcoming issue #4 since you won't have the requisite plan baseline to know if the new partitioning and indexing strategies are giving you the equivalent, or better, performance.
ISSUE#6 - Things can, and will, go wrong and cause delays no matter which approach you take.
So assuming you plan to take care of issues #4 and #5 you will probably have three viable alternatives:
1. use DBMS_REDEFINITION to do the partitioning on-line. See the Oracle docs and this example from oracle-base for more info.
Redefining Tables Online - http://docs.oracle.com/cd/B28359_01/server.111/b28310/tables007.htm
Partitioning an Existing Table using DBMS_REDEFINITION
http://www.oracle-base.com/articles/misc/partitioning-an-existing-table.php
2. do the partitioning offline and hope that you don't exceed your outage window. Recover by continuing to use the existing table.
3. do the partitioning offline but remove the oldest data to minimize the amount of data that has to be worked with.
You should review all of the tables to see if you can remove older data from the current system. If you can you could use online redefinition that ignores older data. Then afterwards you can extract this old data from the old table for archiving.
If the amount of old data is substantial you can extract the new data to a new partitioned table in parallel and not deal with the old data at all.

Range Partitioning on Varchar2 column???

We hava table and it has a date column and its type is varchar2.
This column's format is '16021013' ('ddmmyyyy').
We want to make range partition on this column. What will be the best way?
do you think virtal column partitioning will be efficient?

>
I'm not a new DBA:-) You can be sure. I asked only about range partitioning trick with varchar2 column because we did our examination about this table. We will need to archive this table quarter by quarter to the other archive database. Then, off course, nearly all queries are coming firstly by using this date column and they can have different filtering inside "where" conditions. Already, this table has index on this column but with huge number of data, index performance is not enough for us. This is a 7x24 banking system and we are lately joined to this project. Because of this, we cant change everything like changing data type of that column after this moment.
>
You are taking things way too personally. No one said anything about whether you were, or were not, a DBA or made any other comments about your skill or abilities.
What we ask was for you to tell us WHAT the problem was that you were trying to solve and WHY you thought partitioning would solve it.
And now, after several generic posts, you have finally provided that information. We can only comment based on the information that you post. We can't guess as to what types of queries you use or what kinds of predicates you use in those queries. But we need to know that information in order to provide the best advice.
Next time you post put the important information in your original question:
1. A table column is VARCHAR2 but contains a date value. We are unable to change the datatype of this column.
2. We need to archive data quarterly based on this date value
3. Nearly all queries use this date value and then also may have additional filter conditions
4. This date column is indexed but we would like to improve the performance beyond what this index can give us.
The above is a summary that includes all important information that is needed to know how best to help you.
And I made a pretty good guess since two replies ago I provided you with example code that shows just how to partition the table.
>
Now, our only aim is how to make range partitioning this varchar2 date column.
>
As I showed you in my example code earlier you can add a virtual column to the table and partition on it. My example code creates a monthly partitioned table that allows you to archive by month or archive every three months to archive by quarter.
You can modify that example to use quarterly partitions if you want but I would recommend that you use standard monthly partitions since they will satisfy the widest range of predicates.

Range Partition

Iam getting problem while creating range partition. I have created a partitioned table as below
CREATE TABLE ERROR_DETAILS_tst
STG_TAB_COL_ID NUMBER NOT NULL,
RECORD_ID NUMBER NOT NULL,
ERROR_ID NUMBER NOT NULL,
RECORD_CREATE_DT DATE NOT NULL,
PROGRAM_NAME VARCHAR2(200 BYTE),
ERROR_VALUE VARCHAR2(2000 BYTE),
RECORD_LAST_UPDATE_DT DATE NOT NULL
PARTITION BY RANGE (record_create_dt)
PARTITION P07302007 VALUES LESS THAN (TO_DATE('30-jul-2007', 'dd-mon-yyyy')),
PARTITION P07312007 VALUES LESS THAN (TO_DATE('31-jul-2007', 'dd-mon-yyyy')),
PARTITION P08072007 VALUES LESS THAN (TO_DATE('07-aug-2007', 'dd-mon-yyyy'))
record_create_dt is a timestamp.
Iam trying to insert into this table using
insert into ERROR_DETAILS_tst
select * from error_details_test
But getting ORA-14400: inserted partition key does not map to any partition error.
Since record_create_dt is a timestamp its not getting matched with any of the partitions.
Please suggest.

Now all the records got inserted into 'Other' partition. I want the data to be moved into their respective partitions.
For example I have records with record_create_dt as
8/7/2007 1:45:41 PM
8/7/2007 1:36:44 PM
8/7/2007 1:45:43 PM
8/7/2007 1:45:41 PM
8/7/2007 1:45:42 PM
I want these records to be moved into 'P08072007' partition. Since the record_create_dt is the timestamp these records are not considered for this partition. How can I get this.

About range partition

Dear Friends ,
I am using Oracle10g . I have to create a range partition like below :
CREATE TABLE EMP
EMPNO NUMBER(4),
ENAME VARCHAR2(10 BYTE),
JOB VARCHAR2(9 BYTE),
MGR NUMBER(4),
HIREDATE DATE,
SAL NUMBER(7,2),
COMM NUMBER(7,2),
DEPTNO NUMBER(2)
PARTITION BY RANGE(hiredate)
PARTITION emp_1980 VALUES LESS THAN(TO_DATE('31/12/1980','DD/MM/YYYY')) TABLESPACE USERS,
PARTITION emp_1981 VALUES LESS THAN(TO_DATE('31/12/1981','DD/MM/YYYY')) TABLESPACE USERS,
PARTITION emp_1982 VALUES LESS THAN(TO_DATE('31/12/1982','DD/MM/YYYY')) TABLESPACE USERS,
PARTITION emp_1987 VALUES LESS THAN(TO_DATE('31/12/1987','DD/MM/YYYY')) TABLESPACE USERS
But the problem is :
1) if any input data is not match with the above criteria then where it goes ? i mean , the data which dont follow the above rule which partition it goes ? is there any way to set DEFAULT partition option in the range partition ?
I only find the DEFAULT option in LIST partition
2) Barring this , when I add a new partition with the above then it shows the below error :
alter table emp add partition emp.emp_1988 VALUES LESS THAN(TO_DATE('31/12/1988','DD/MM/YYYY')) TABLESPACE USERS
Error :
"ORA-14020: this physical attribute may not be specified for a table partition" ,
Would anybody plz help me , How can I solve the above problems ?

Range Partitioning provides for a range of values. Therefore, any value higher than the maximum value provided in your partition definitions would fail. Thus, for example, 01/01/1988 and above would error. That is why Range Partitioning allows you to specify a "highest" values possible where you say "values less than (MAXVALUE)". Therefore, if you had included an "emp_maxvalue" partition with "values less than (MAXVALUE)" after the "emp_1987" partition, any value for 1988 or higher would go into the emp_maxvalue partition.
{ Since there is no minvalue specified, a value of, say, 01/06/1979 would go into the "emp_1980" partition as it is "less than (01/01/1980)" ! }
Again, as Partitioning is a Range of Dates, you cannot add a partition. You have to SPLIT a partition. For example, if you had an "emp_maxvalue" partition present, in order to create the emp_1988 partition, you would SPLIT "emp_maxvalue" into two partitions : emp_1988 and emp_maxvalue.
Please read the documentation on Partition Maintenance in the Administrator's Guide.
Hemant K Chitale
http://hemantoracledba.blogspot.com

Range Partition Concept

Hi,
I am having problem understanding a concept of Range Partition. While creating a range based partition this is the syntax generally used:
CREATE TABLE emp (
empno NUMBER(4),
ename VARCHAR2(30),
sal NUMBER
PARTITION BY RANGE(empno) (
partition e1 values less than (1000) tablespace ts1,
partition e2 values less than (2000) tablespace ts2,
partition e3 values less than (3000) tablespace ts3,
partition e4 values less than (4000) tablespace ts4,
partition em values less than (MAXVALUE) tablespace tsm
As per the above logic an empno with value 1500 would be inserted into tablespace e2. But the value 1500 is also less than 3000, then how to confirm (or why) that this is not getting inserted into tablespace e3.
DB Version: 10.2.0.1
Platform: Generic
Thanks for your valuable time.
Regards,
Joy

As per the above logic an empno with value 1500 would be inserted into tablespace e2.Yes you are right
But the value 1500 is also less than 3000, then how to confirm (or why) that this is not getting inserted into tablespace e3.Because e3 partition also implicitly denotes "greater than 2000" apart from less than 3000.
lesser than the value you mentioned & greater than that the previous partition value (if applicable)
When using range partitioning, consider the following rules:
* Each partition has a VALUES LESS THAN clause, which specifies a noninclusive upper bound for the partitions. Any binary values of the partition key equal to or higher than this literal are added to the next higher partition.
** All partitions, except the first, have an implicit lower bound specified by the VALUES LESS THAN clause on the previous partition.*
* A MAXVALUE literal can be defined for the highest partition. MAXVALUE represents a virtual infinite value that sorts higher than any other possible value for the partition key, including the null value.
HTH..

Composite range - range partitioning gives ORA-14202

i am trying to do e composite range - range partitioning, but the table is not created. i get an error, which i cannot look up at ora-codes, it says : value is to high for subpartition, which confuses me...
CREATE TABLE "NJ_VE_AERIAL_RDT"
(     "RASTERID" NUMBER NOT NULL ENABLE,
"BANDBLOCKNUMBER" NUMBER NOT NULL ENABLE,
     "PYRAMIDLEVEL" NUMBER NOT NULL ENABLE,
     "ROWBLOCKNUMBER" NUMBER NOT NULL ENABLE,
     "COLUMNBLOCKNUMBER" NUMBER NOT NULL ENABLE,
     "FILENAME" VARCHAR2(100 CHAR) NOT NULL ENABLE,
     "FILESIZE" NUMBER(12,0) NOT NULL ENABLE,
     "NORTH" NUMBER(19,15) NOT NULL ENABLE,
     "SOUTH" NUMBER(19,15) NOT NULL ENABLE,
     "EAST" NUMBER(19,15) NOT NULL ENABLE,
     "WEST" NUMBER(19,15) NOT NULL ENABLE,
     "BLOCKMBR" "MDSYS"."SDO_GEOMETRY" ,
     "RASTERBLOCK" BLOB,
     "INFO_CREATOR" VARCHAR2(100 BYTE) DEFAULT 'novalue' NOT NULL ENABLE,
     "INFO_CREATED" TIMESTAMP (6) WITH LOCAL TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL ENABLE,
     "INFO_LASTMODIFIER" VARCHAR2(100 CHAR) DEFAULT 'novalue' NOT NULL ENABLE,
     "INFO_LASTMODIEFIER" TIMESTAMP (6) WITH LOCAL TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL ENABLE,
     CONSTRAINT "NJ_VE_RDT_PK" PRIMARY KEY
("RASTERID"
,"BANDBLOCKNUMBER"
,"PYRAMIDLEVEL"
,"ROWBLOCKNUMBER"
,"COLUMNBLOCKNUMBER"))
PARTITION BY RANGE (WEST) INTERVAL (1)
SUBPARTION BY RANGE (NORTH)
SUBPARTITION TMEPLATE (
SUBPARTITION s0 VALUES LESS THAN (15)
,SUBPARTITION s0 VALUES LESS THAN (5)
(PARTITION p0 VALUES LESS THAN (0));
What is my problem ? My current solution is fully dropping subpartitioning. but thats a cheesy workaround...
ingo
Message was edited by:
Ingo Jannick

achso ?!
this works, but even switching the subpartition definitions results in the mentioned error. adding another sub does the same.
my guess is that it is a range by interval issue. i have to figure that out...
Working:
CREATE TABLE "NJ_VEL_RDT"
(     "RASTERID" NUMBER NOT NULL ENABLE,
"BANDBLOCKNUMBER" NUMBER NOT NULL ENABLE,
     "PYRAMIDLEVEL" NUMBER NOT NULL ENABLE,
     "ROWBLOCKNUMBER" NUMBER NOT NULL ENABLE,
     "COLUMNBLOCKNUMBER" NUMBER NOT NULL ENABLE,
     "FILENAME" VARCHAR2(100 CHAR) NOT NULL ENABLE,
     "FILESIZE" NUMBER(12,0) NOT NULL ENABLE,
     "NORTH" NUMBER(19,15) NOT NULL ENABLE,
     "SOUTH" NUMBER(19,15) NOT NULL ENABLE,
     "EAST" NUMBER(19,15) NOT NULL ENABLE,
     "WEST" NUMBER(19,15) NOT NULL ENABLE,
     "BLOCKMBR" "MDSYS"."SDO_GEOMETRY" ,
     "RASTERBLOCK" BLOB,
     "INFO_CREATOR" VARCHAR2(100 BYTE) DEFAULT 'novalue' NOT NULL ENABLE,
     "INFO_CREATED" TIMESTAMP (6) WITH LOCAL TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL ENABLE,
     "INFO_LASTMODIFIER" VARCHAR2(100 CHAR) DEFAULT 'novalue' NOT NULL ENABLE,
     "INFO_LASTMODIEFIER" TIMESTAMP (6) WITH LOCAL TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL ENABLE,
     CONSTRAINT "NJ_VE_PK" PRIMARY KEY
( "RASTERID",
"BANDBLOCKNUMBER",
"PYRAMIDLEVEL",
"ROWBLOCKNUMBER",
"COLUMNBLOCKNUMBER"))
PARTITION BY RANGE(WEST) INTERVAL (5)
SUBPARTITION BY RANGE(NORTH)
SUBPARTITION TEMPLATE
SUBPARTITION s1 VALUES LESS THAN (65)
,SUBPARTITION s0 VALUES LESS THAN (MAXVALUE)
(PARTITION p0 VALUES LESS THAN (15))
;

After creating partition, problems start

I use Boot Camp Asst. and create a 32 GB partition. at the end of the process, I'm told to "hit the Restart key or hold the power key for a few seconds." Since i have no restart key on my MacBook, I hold down the power key. Then the system turns off. I turn it on again, and reboot. I get an error - osx shut down unexpectedly, do i want to report to apple. whatever. the space i allocated on the partition is gone from my free space, but if I go into BCA, it doesn't seem to know that i've already created a partition. things are screwy and i have to reboot from the Leopard disk and use Disk Utility to repair the disk.
So, how do I get around this? I really want to use boot camp.

I have it all fixed (except that the Windows XP system won't completely shut down or restart into any startup volume...I have to hold down the power button until shutdown, then start by pressing the start button).
AppleCare tech, on two different calls, spoke of a bug in OS X (10.5.2) that is causing the partition problem described by me and others in this thread.
The solution (assuming that you don't have a Windows partition yet) is to install OS X (10.5.1). Don't do any software updates to 10.5.1 until you've completed the Windows install using Boot Camp Assistant.
Remember to have backups.
I didn't exactly follow the solution directly. I reinstalled Tiger 10.4.11. Then I installed 10.5.1 as an upgrade. The reason for this is that I was not warned by AppleCare tech that a 10.5.2 install using "erase and install" would delete the entire iLife '06 suite. I lost iLife '06. That's why I reverted to Tiger before attempting the Leopard and Boot Camp installations.

I updated my IPhone 3GS to the new 5.1 operating system and have since had a range of problems with not only my phone but also my IPad.

I updated my IPhone 3GS to the new 5.1 operating system and have since had a range of problems with not only my phone but also my IPad.
Programs (Safari, mail, messages) keep crashing, mail will not delete properly (some will keep popping into my inbox again for no reason!!!), slow, settings lock up etc. etc.
This only seemed to become an issue once I updated to ios 5.1 and funnily also affected my Ipad even though i hadn't updated the software yet. I have since updated the software on my ipad thinking it might help too but that only made things worse!! So I am not sure if it's an ICloud issue, but when i try to disable ICloud my devices lock up as well.
The battery life is also shocking!!
I have hard reset both devices, restored both devices, reset the setting and tried a whole host of other suggestions (like closing background programs) on this forum buit nothing works and i am tearing my hair out.
I looked in the phone and ipad log and there do seem to be low memory reports though i don't know why these are occuring now when they never have before??
I don't know if I can restore the old operating system (If I can please let me know how). The phone or ipad are not jailbroken.

but you should have a backup in itunes.
Every time you sync your iOS device iTunes creates a backup. go check if its there, iTunes Preferences >Devices. and there you should see if you have a backup, and in case from which date the backup is.
And ofcourse you can get your icloud data back by just logging in with your Appleid under icloud in settings on the iphone.
But anyway, if the iPhone works when you restor it as new: try adding your backup, and see if the issue comes back. And experiment with your backup and try to work out what is causing the issue, my guess is that its some app! Good Luck!

Create range partition

hi ,
Oracle 10.2.0.1.0
I'm getting error while creating a range partition to already existing table (method employed : partition swap method ) .
PF screen shot of error
SQL> ed
Wrote file afiedt.buf
1 create table employee_details_temp partition by range (eid) (
2 partition eid_1r values less than (1000)
3 partition eid_2r values less than (20000)
4 partition eid_3r values less than (40000)
5 partition eid_3r values less than (maxvalue)
6* )
SQL> /
partition eid_2r values less than (20000)
ERROR at line 3:
ORA-14020: this physical attribute may not be specified for a table partitionalso ,
SQL> ed
Wrote file afiedt.buf
1 create table employee_details_temp partition by range (eid) (
2 partition eid_1r values less than (1000)
3 partition eid_2r values less than (20000)
4 partition eid_3r values less than (40000)
5 partition eid_3r values less than (maxvalue)
6 ) as select * from employee_details where 1=1;
7* /
SQL> /
partition eid_2r values less than (20000)
ERROR at line 3:
ORA-14020: this physical attribute may not be specified for a table partition please help .

answered .

How to find out the min & max partition_id in a range partition?

Hi we have a table set up by range partition
In the table creation script. It goes something like:
PARTITION PARTD_CUST_3_1_NEW VALUES LESS THAN ('39500')
so how we can find out this number '39500' from some of the data_dictionary view?
What we want to do is to set up parallel processing (do-it-yourself) based on partition.
So the number of parallel process will be based on this ID-range.
I can find out how many partitions are there by using something like this:
SELECT COUNT(*)
FROM all_tab_partitions WHERE table_owner='OWNER_NAME' AND table_name='TABLE_NAME'
We have 5 partitions now but the table structure can change in the near future even this table has moer than 130Million rows
I do not want to hardcode this "39500" just in case the table structure changes (partition structure changes)
Any idea ??

vxwo0owxv wrote:
Hi we have a table set up by range partition
In the table creation script. It goes something like:
PARTITION PARTD_CUST_3_1_NEW VALUES LESS THAN ('39500')
so how we can find out this number '39500' from some of the data_dictionary view?
What we want to do is to set up parallel processing (do-it-yourself) based on partition.
So the number of parallel process will be based on this ID-range.
I can find out how many partitions are there by using something like this:
SELECT COUNT(*)
FROM all_tab_partitions WHERE table_owner='OWNER_NAME' AND table_name='TABLE_NAME'
We have 5 partitions now but the table structure can change in the near future even this table has moer than 130Million rows
I do not want to hardcode this "39500" just in case the table structure changes (partition structure changes)
Any idea ??query DBA_TAB_PARTITIONS.HIGH_VALUE

Non-Partitioned Global Index on Range-Partitioned Table.

Hi All,
Is it possible to create Non-Partitioned Global Index on Range-Partitioned Table?
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Please help me in identifying other 3 indexes types by referring below ouputs!!!
select INDEX_NAME,TABLE_NAME,PARTITIONING_TYPE,LOCALITY from dba_part_indexes where TABLE_NAME='CS_BILLING';
INDEX_NAME TABLE_NAME PARTITI LOCALI
CSB_CLIENT_CODE CS_BILLING RANGE LOCAL
select index_name,index_type,table_name,table_type,PARTITIONED from dba_indexes where table_name='CS_BILLING';
INDEX_NAME INDEX_TYPE TABLE_NAME TABLE_TYPE PAR
CSB_CREATE_DATE NORMAL CS_BILLING TABLE NO
CSB_SUBMIT_ORDER NORMAL CS_BILLING TABLE NO
CSB_CLIENT_CODE NORMAL CS_BILLING TABLE YES
CSB_ORDER_NBR NORMAL CS_BILLING TABLE NO
select INDEX_OWNER,INDEX_NAME,TABLE_NAME,COLUMN_NAME from dba_ind_columns where TABLE_NAME='CS_BILLING';
INDEX_OWNER INDEX_NAME TABLE_NAME COLUMN_NAME
RPADMIN CSB_CREATE_DATE CS_BILLING CREATE_DATE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING SUBMIT_TO_INVOICE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING ORDER_NBR
RPADMIN CSB_CLIENT_CODE CS_BILLING CLIENT_CODE
RPADMIN CSB_ORDER_NBR CS_BILLING ORDER_NBR
select dip.index_name, dpi.locality, dip.partition_name, dip.status
from dba_part_indexes dpi, dba_ind_partitions dip
where dpi.table_name ='CS_BILLING'
and dpi.index_name = dip.index_name;
INDEX_NAME LOCALI PARTITION_NAME STATUS
CSB_CLIENT_CODE LOCAL CSB_2006_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2006_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_4Q USABLE
select * from dba_part_indexes
where table_name ='CS_BILLING'
and locality = 'GLOBAL';
no rows selected
-Yasser
Edited by: YasserRACDBA on Mar 5, 2009 11:45 PM

Yaseer,
Is it possible to create Non-Partitioned and Global Index on Range-Partitioned Table?
Yes
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
You got local index and 3 non-partitioned "NORMAL" b-tree tyep indexes
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Above staement will create non-partitioned index
Here is an example of creating global partitioned indexes
CREATE INDEX month_ix ON sales(sales_month)
   GLOBAL PARTITION BY RANGE(sales_month)
      (PARTITION pm1_ix VALUES LESS THAN (2)
       PARTITION pm2_ix VALUES LESS THAN (3)
       PARTITION pm3_ix VALUES LESS THAN (4)
        PARTITION pm12_ix VALUES LESS THAN (MAXVALUE));Regards

Range Partition Problem

Similar Messages

Maybe you are looking for