Resizing a Column in a Table With a Spatial Column
Recently a client asked for help with using DBMS_REDEFINITION to modify a column in a table.
As the intent was to reduce the precision of a numeric column, simply modifying the column would not work, as there was already data in the column:
13:51:44 ora11203fs.jks.com - jkstill@js01 SQL> / alter table t modify(id number(6,2)) * ERROR at line 1: ORA-01440: column to be modified must be empty to decrease precision or scale
The client had made a few attempts use DBMS_REDEFINITION, but ran into several issues with each attempt.
In this case the owner of the destination table was different than the owner of the source table.
As per My Oracle Support, this situation requires several permissions granted that may not normally be necessary for using DBMS_REDEFINITION.
However I have seen similar problems when the source and destination user are the same.
The version of database for the client is 11.2.0.3 running on Solaris
These test are also performed on 11.2.0.3, but on Linux 5 rather than Solaris.
Most of the issues involve permissions that must be granted to the owner of the destination object.
This is true even if the job is being run as SYSDBA.
These errors were due to the table in question having a column of spatial data with a corresponding spatial index.
17:27:49 ora11203fs.jks.com – sys@js01 SQL> desc spdata
Name Null? Type
———————————————– ——– ——————————–
ID NOT NULL NUMBER(28)
RADIUS NOT NULL NUMBER(16,8)
LOCATION NOT NULL MDSYS.SDO_GEOMETRY
Workflow
The information in this article will be presented somewhat backwards to the way that is usually seen.
First I will show a working example of using DBMS_REDEFINITION to redefine the column.
Following that some of the problems will be highlighted, and then some technical references shown.
Doing so will make this article a little more user friendly I think.
If you are facing a similar issue then the parts you need the most are right up front.
A Working Example
Following are the steps to create the test data, setup DBMS_REDEFINITION and complete the process
Create the Test Data
The first step is to create a test user. The permissions granted to this user are quite important, as will be demonstrated later on.
-- redefdest_user.sql create user redefdest identified by redefdest; grant resource, connect, create session, unlimited tablespace to redefdest; grant alter session to redefdest; grant execute on dbms_redefinition to redefdest; grant create any sequence to redefdest; grant create any table to redefdest; grant alter any table to redefdest; grant drop any table to redefdest; grant lock any table to redefdest; grant select any table to redefdest; grant create any index to redefdest; grant create any trigger to redefdest;
Once this process is completed, remember to revoke any privileges that are not needed on a permanent basis.
Now let’s create a simple table with some spatial data:
-- tab_create.sql create table redefdest.spdata ( id number(28,0) not null, radius number(16,8) not null, location mdsys.sdo_geometry not null );
The next step is to setup the Geometry Metadata. This must be run as the owner of the SPDATA table.
-- insert_geo_data.sql
delete from user_sdo_geom_metadata where table_name = 'SPDATA' and column_name = 'LOCATION';
insert into user_sdo_geom_metadata
(table_name, column_name, diminfo, srid)
values
(
'SPDATA', 'LOCATION',
sdo_dim_array (
sdo_dim_element ('Longitude', -180, 180, 0.005),
sdo_dim_element ('Latitude', -90, 90, 0.005)
),
8307 -- SRID - Spatial Reference IDentifier - see mdsys.cs_srs
);
commit;
select * from user_sdo_geom_metadata;
Now we can insert some test data into the table.
-- insert.sql
insert into spdata(id, radius, location)
select
id,
dbms_random.value(10000,20000),
sdo_geometry(2001, 8307,
sdo_point_type (floor(dbms_random.value(-180,180)),floor(dbms_random.value(-90,90)) , null),
null, null
)
from (
select level id
from dual
connect by level <= 100
) data;
commit;
Now create indexes on the ID column and the spatial data column.
-- idx_create.sql
create index redefdest.spdata_id_idx on redefdest.spdata (id);
create index redefdest.spdata_location_idx on redefdest.spdata (location)
indextype is mdsys.spatial_index parameters ('SDO_DML_BATCH_SIZE=2000');
Configure DBMS_REDEFINITION
The goal of this excercise is to change the scale and precision of the RADIUS column.
That cannot be done directly via ALTER TABLE as any attempt to so will cause ORA-01440.
The first task is to create the interim table. This table will be created nearly identical to the source table. The RADIUS column in the interim table will have a smaller scale and precision than the source table.
The columns for the table SPDATA_INTERIM are all set as nullable.
The reason for the will be explained later on.
-- create_interim_table.sql create table redefdest.spdata_interim ( id number(28,0), radius number(12,4), location mdsys.sdo_geometry );
Now geo data for the interim table must be created. This is not the same script as seen previously. Though the script name is the same, it is stored in a different directory. The only difference from the previous script is the name of the table used – SPDATA_INTERIM rather than SPDATA.
As before, this SQL must be run as the owner of the table in question, SPDATA_INTERIM in this case.
-- insert_geo_data.sql
insert into user_sdo_geom_metadata
(table_name, column_name, diminfo, srid)
VALUES
(
'SPDATA_INTERIM', 'LOCATION',
sdo_dim_array (
sdo_dim_element ('Longitude', -180, 180, 0.005),
sdo_dim_element ('Latitude', -90, 90, 0.005)
),
8307 -- SRID - see mdsys.cs_srs
)
/
commit;
Now that the interim table has been created and the geo data inserted, the redefinition process can begin:
-- redefine.sql 1 declare 2 v_col_map varchar(2048) := 'ID ,RADIUS ,LOCATION'; 3 begin 4 dbms_redefinition.start_redef_table ( 5 uname => 'REDEFDEST' 6 ,orig_table => 'SPDATA' 7 ,int_table => 'SPDATA_INTERIM' 8 ,col_mapping => v_col_map 9 ,options_flag => dbms_redefinition.cons_use_rowid 10 ,orderby_cols => null 11 ,part_name => null 12 ); 13* end; 17:34:51 ora11203fs.jks.com - jkstill@js01 SQL> / PL/SQL procedure successfully completed.
Once the refinition process has completed, the dependent objects can be created.
-- copy_dependent_objects.sql
Wrote file afiedt.buf
1 declare
2 v_number_of_errors number := 0;
3 begin
4 dbms_redefinition.copy_table_dependents(
5 uname => 'REDEFDEST'
6 ,orig_table => 'SPDATA'
7 ,int_table => 'SPDATA_INTERIM'
8 ,copy_indexes => dbms_redefinition.cons_orig_params
9 ,copy_triggers => true
10 ,copy_constraints => true
11 ,copy_privileges => true
12 ,ignore_errors => false
13 ,num_errors => v_number_of_errors
14 ,copy_statistics => true
15 ,copy_mvlog => true
16 );
17 dbms_output.put_line('Number of Errors' || v_number_of_errors);
18* END;
17:35:58 ora11203fs.jks.com - jkstill@js01 SQL> /
PL/SQL procedure successfully completed.
And now finish the redefinition process, check the SPDATA.RADIUS column to ensure it is now NUBMER(12,4), and drop the interim table (now the original table)
-- finish_redef.sql
1 begin
2 dbms_redefinition.finish_redef_table (
3 uname => 'REDEFDEST'
4 ,orig_table => 'SPDATA'
5 ,int_table => 'SPDATA_INTERIM'
6 );
7* end;
17:35:59 ora11203fs.jks.com - jkstill@js01 SQL> /
17:36:43 ora11203fs.jks.com - jkstill@js01 SQL> alter table redefdest.spdata modify (id not null);
Table altered.
17:44:05 ora11203fs.jks.com - jkstill@js01 SQL> alter table redefdest.spdata modify (radius not null);
alter table redefdest.spdata modify (radius not null)
*
ERROR at line 1:
ORA-01442: column to be modified to NOT NULL is already NOT NULL
17:44:05 ora11203fs.jks.com - jkstill@js01 SQL> alter table redefdest.spdata modify (location not null);
Table altered.
PL/SQL procedure successfully completed.
16:01:40 ora112304a.jks.com - redefdest@js02 SQL> desc spdata
Name Null? Type
----------------------------------------- -------- ----------------------------
ID NOT NULL NUMBER(28)
RADIUS NUMBER(12,4)
LOCATION NOT NULL MDSYS.SDO_GEOMETRY
16:01:40 ora112304a.jks.com - redefdest@js02 SQL> select count(*) from spdata where radius is not null;
COUNT(*)
----------
100
With all of the required permissions in place, everything works as expected.
Getting to that point however required reading a few Oracle Support notes and some experimentation.
There are several ways this process can fail if one of the requirements is not met.
Alter/Create/Drop Any Table
If the owner of the tables is missing any of ALTER/CREATE/DROP ANY TABLE, the process will fail when copying dependent objects.
This due to a bug in Oracle.
In this test the CREATE ANY TABLE privilege has been revoked, and the entire test re-run:
18:04:25 ora11203fs.jks.com - sys@js01 SQL> revoke create any table from redefdest; Revoke succeeded. ## Copy Dependents ## declare * ERROR at line 1: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-13249: internal error in Spatial index: [mdidxrbd] ORA-13249: Error in Spatial index: index build failed ORA-13249: Error in R-tree: [mdrcrtscrt] ORA-13231: failed to create index table [MDRT_190DB$] during R-tree creation ORA-13249: Stmt-Execute Failure: CREATE TABLE "REDEFDEST".MDRT_190DB$ (NODE_ID NUMBER, NODE_LEVEL NUMBER, INFO BLOB) LOB (INFO) STORE AS (NOCACHE) PCTFREE 2 ORA-29400: data cartridge error ORA-01031: insufficient privileges ORA-06512: at "SYS.DBMS_REDEFINITION", line 1155 ORA-06512: at "SYS.DBMS_REDEFINITION", line 1885 ORA-06512: at line 4
Likewise if CREATE ANY SEQUENCE is revoked, the process will fail.
(CREATE ANY TABLE had already been re-granted)
18:12:23 ora11203fs.jks.com - sys@js01 SQL> revoke create any sequence from redefdest; Revoke succeeded. ## Copy Dependents ## declare * ERROR at line 1: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-13249: internal error in Spatial index: [mdidxrbd] ORA-13249: Error in Spatial index: index build failed ORA-13249: Error in R-tree: [mdrcrtscrt] ORA-13231: failed to create index table [MDRS_190F9$] during R-tree creation ORA-13249: Stmt-Execute Failure: CREATE SEQUENCE "REDEFDEST".MDRS_190F9$ ORDER START WITH 1 CACHE 100 ORA-29400: data cartridge error ORA-01031: insufficient privileges ORA-06512: at "SYS.DBMS_REDEFINITION", line 1155 ORA-06512: at "SYS.DBMS_REDEFINITION", line 1885 ORA-06512: at line 4
So each of these permission are required for this process to succeed, even when running as SYSDBA.
Permissions Required
The test objects created for this article are quite simple.
As such there are other potential errors that could occur due to the destination account not having all required permissions for a successful use of dbms_redefinition on a table with spatial data.
Before granting new privileges to an account, be sure to audit the current privileges.
That way you will know which privileges can be safely revoked when the table modifications are complete.
Constraint Issues
There are some bugs associated with DBMS_REDEFINITION.
The COPY_DEPENDENT_OBJECTS subprogram seemingly does not handle some constraints very well.
The original table SPDATA was created with all columns set to NOT NULL.
The interim table SPDATA_INTERIM was created with all columns set to NULL.
If the interim table is created with one or more columns as NOT NULL, the following error occurs:
## Copy Dependents ## declare * ERROR at line 1: ORA-01442: column to be modified to NOT NULL is already NOT NULL ORA-06512: at "SYS.DBMS_REDEFINITION", line 984 ORA-06512: at "SYS.DBMS_REDEFINITION", line 1899 ORA-06512: at line 4
Part of the job of the procedure is to create check constraints as found on the original table.
That part of the process doesn’t seem to work quite correctly.
When the process has completed, the columns appear as NULLable to the sqlplus DESC command, but that is not the case.
18:21:15 ora11203fs.jks.com - jkstill@js01 SQL> desc spdata
Name Null? Type
----------------------------------------------------------------- -------- --------------------------------------------
ID NUMBER(28)
RADIUS NUMBER(12,4)
LOCATION MDSYS.SDO_GEOMETRY
18:21:17 ora11203fs.jks.com - jkstill@js01 SQL> insert into spdata values(null,null,null);
insert into spdata values(null,null,null)
*
ERROR at line 1:
ORA-01400: cannot insert NULL into ("REDEFDEST"."SPDATA"."ID")
18:21:35 ora11203fs.jks.com - jkstill@js01 SQL> @check_cons
TABLE NAME CONSTRAINT_NAME C SEARCH_CONDITION STATUS
------------------------------ ------------------------------ - ------------------------------ --------
SPDATA SYS_C0018231 C "ID" IS NOT NULL ENABLED
SPDATA SYS_C0018232 C "RADIUS" IS NOT NULL ENABLED
SPDATA SYS_C0018233 F "LOCATION" IS NOT NULL ENABLED
3 rows selected.
The output of the DESC command and the contents of DBA_CONSTRAINTS do not agree.
While it would be interesting to dig into the lower level reasons for why this is happening, it for now just an inconvience while there are more pressing matters to work on.
References
Following are the Oracle Notes considered when troubleshooting this issue.
Registering constraints
The DBMS_REDEFINITION.REGISTER_DEPENDENT_OBJECT procedure could be used to better deal with constraints, at least according to this Oracle Note:
HOW TO USE DBMS_REDEFINITION.REGISTER_DEPENDENT_OBJECT (Doc ID 1304838.1)
I have not yet tried this.
In regard to desc table not showing constraints
This may be the issue: Bug 16023293 : DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS DOES NOT VALIDATE ALL CONSTRAINTS
This bug affects Oracle 11.2.0.3 on Solaris, so it seems likely to be an issue for the client, and may well affect other platforms as well.
Direct privs granted to table owner
How to Re-Organize a Table Online (Doc ID 177407.1)
ORA-13233 and ORA-01031 When Creating a Spatial Index in Another Schema (Doc ID 251593.1)