Splitting table partition

Hi All,
I have a table with several partitions. The latest partition (key is date column) has values less than MAXVALUE. The table has several local indexes on it. It's too large and I'd like to split the latest partition. I have the following questions:
1. Can I simply split the partion and expect everything to work
2. What about indexes, do I have to re-create them or will they be split along with the table ?. I'd like to specify a new tablespace for the newly partitioned index. How can I do that
3. How can I specify a tablespace for the newly partition data ? Should I move the rows between tablespaces after the split
4. Can anyone share any experience with me.
The database is Oracle 9i. Any help is higly appreciated.
Thanks a lot
Vissu

1. Yes, it works fine
2. Yes u have to recreate the index
alter index my_index rebuild partition my_partition tablespace new_tablespace ;
3. check the syntax of the split partition command :-)
4. Yes :-) all works really fine, i have ever split partition, exchange partition, everything works really fine
Fred

Similar Messages

Split Oracle 11g Table Partition and Insert new rows

Hi,
I have a doubt that i would like to be clarified. I need to split a partition of a table with more than 800 Million records, but at the same time (during the split operation) i need to insert new records (not in the partition that is being splited). Is there any problem/risk doing this? Is the insert ETL process going to fail ?
Thanks in advance
Greetings.
Nuno
Edited by: user13512889 on 1/Set/2011 3:25

Hi Enrique,
Thanks for posting in MSDN.
Based on the description, you want to modify the formula for the A1 and B1 cell when you insert a new rows.
Yes, we can use Worksheet.Change to dermin the change of data on the worksheet then we can modify the formula as we wanted. Here is a sample for your reference:
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
Me.Range("A1").Formula = "=MAX($A2:$A" & Me.UsedRange.Rows.Count & ")"
Me.Range("B1").Formula = "=MIN($B2:$B" & Me.UsedRange.Rows.Count & ")"
End Sub
You can more detail about Excel VBA developing from link below:
Getting Started with VBA in Excel 2010
Welcome to the Excel 2013 developer reference
Regards & Fei
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Sliding Window Table Partitioning Problems with RANGE RIGHT, SPLIT, MERGE using Multiple File Groups

There is misleading information in two system views (sys.data_spaces & sys.destination_data_spaces) about the physical location of data after a partitioning MERGE and before an INDEX REBUILD operation on a partitioned table. In SQL Server 2012 SP1 CU6,
the script below (SQLCMD mode, set DataDrive & LogDrive variables for the runtime environment) will create a test database with file groups and files to support a partitioned table. The partition function and scheme spread the test data across
4 files groups, an empty partition, file group and file are maintained at the start and end of the range. A problem occurs after the SWITCH and MERGE RANGE operations, the views sys.data_spaces & sys.destination_data_spaces show the logical, not the physical,
location of data.
--=================================================================================
-- PartitionLabSetup_RangeRight.sql
-- 001. Create test database
-- 002. Add file groups and files
-- 003. Create partition function and schema
-- 004. Create and populate a test table
--=================================================================================
USE [master]
GO
-- 001 - Create Test Database
:SETVAR DataDrive "D:\SQL\Data\"
:SETVAR LogDrive "D:\SQL\Logs\"
:SETVAR DatabaseName "workspace"
:SETVAR TableName "TestTable"
-- Drop if exists and create Database
IF DATABASEPROPERTYEX(N'$(databasename)','Status') IS NOT NULL
BEGIN
ALTER DATABASE $(DatabaseName) SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DROP DATABASE $(DatabaseName)
END
CREATE DATABASE $(DatabaseName)
ON
( NAME = $(DatabaseName)_data,
FILENAME = N'$(DataDrive)$(DatabaseName)_data.mdf',
SIZE = 10,
MAXSIZE = 500,
FILEGROWTH = 5 )
LOG ON
( NAME = $(DatabaseName)_log,
FILENAME = N'$(LogDrive)$(DatabaseName).ldf',
SIZE = 5MB,
MAXSIZE = 5000MB,
FILEGROWTH = 5MB ) ;
GO
-- 002. Add file groups and files
--:SETVAR DatabaseName "workspace"
--:SETVAR TableName "TestTable"
--:SETVAR DataDrive "D:\SQL\Data\"
--:SETVAR LogDrive "D:\SQL\Logs\"
DECLARE @nSQL NVARCHAR(2000) ;
DECLARE @x INT = 1;
WHILE @x <= 6
BEGIN
SELECT @nSQL =
'ALTER DATABASE $(DatabaseName)
ADD FILEGROUP $(TableName)_fg' + RTRIM(CAST(@x AS CHAR(5))) + ';
ALTER DATABASE $(DatabaseName)
ADD FILE
NAME= ''$(TableName)_f' + CAST(@x AS CHAR(5)) + ''',
FILENAME = ''$(DataDrive)\$(TableName)_f' + RTRIM(CAST(@x AS CHAR(5))) + '.ndf''
TO FILEGROUP $(TableName)_fg' + RTRIM(CAST(@x AS CHAR(5))) + ';'
EXEC sp_executeSQL @nSQL;
SET @x = @x + 1;
END
-- 003. Create partition function and schema
--:SETVAR TableName "TestTable"
--:SETVAR DatabaseName "workspace"
USE $(DatabaseName);
CREATE PARTITION FUNCTION $(TableName)_func (int)
AS RANGE RIGHT FOR VALUES
0,
15,
30,
45,
60
CREATE PARTITION SCHEME $(TableName)_scheme
AS
PARTITION $(TableName)_func
TO
$(TableName)_fg1,
$(TableName)_fg2,
$(TableName)_fg3,
$(TableName)_fg4,
$(TableName)_fg5,
$(TableName)_fg6
-- Create TestTable
--:SETVAR TableName "TestTable"
--:SETVAR BackupDrive "D:\SQL\Backups\"
--:SETVAR DatabaseName "workspace"
CREATE TABLE [dbo].$(TableName)(
[Partition_PK] [int] NOT NULL,
[GUID_PK] [uniqueidentifier] NOT NULL,
[CreateDate] [datetime] NULL,
[CreateServer] [nvarchar](50) NULL,
[RandomNbr] [int] NULL,
CONSTRAINT [PK_$(TableName)] PRIMARY KEY CLUSTERED
[Partition_PK] ASC,
[GUID_PK] ASC
) ON $(TableName)_scheme(Partition_PK)
) ON $(TableName)_scheme(Partition_PK)
ALTER TABLE [dbo].$(TableName) ADD CONSTRAINT [DF_$(TableName)_GUID_PK] DEFAULT (newid()) FOR [GUID_PK]
ALTER TABLE [dbo].$(TableName) ADD CONSTRAINT [DF_$(TableName)_CreateDate] DEFAULT (getdate()) FOR [CreateDate]
ALTER TABLE [dbo].$(TableName) ADD CONSTRAINT [DF_$(TableName)_CreateServer] DEFAULT (@@servername) FOR [CreateServer]
-- 004. Create and populate a test table
-- Load TestTable Data - Seconds 0-59 are used as the Partitoning Key
--:SETVAR TableName "TestTable"
SET NOCOUNT ON;
DECLARE @Now DATETIME = GETDATE()
WHILE @Now > DATEADD(minute,-1,GETDATE())
BEGIN
INSERT INTO [dbo].$(TableName)
([Partition_PK]
,[RandomNbr])
VALUES
DATEPART(second,GETDATE())
,ROUND((RAND() * 100),0)
END
-- Confirm table partitioning - http://lextonr.wordpress.com/tag/sys-destination_data_spaces/
SELECT
N'DatabaseName' = DB_NAME()
, N'SchemaName' = s.name
, N'TableName' = o.name
, N'IndexName' = i.name
, N'IndexType' = i.type_desc
, N'PartitionScheme' = ps.name
, N'DataSpaceName' = ds.name
, N'DataSpaceType' = ds.type_desc
, N'PartitionFunction' = pf.name
, N'PartitionNumber' = dds.destination_id
, N'BoundaryValue' = prv.value
, N'RightBoundary' = pf.boundary_value_on_right
, N'PartitionFileGroup' = ds2.name
, N'RowsOfData' = p.[rows]
FROM
sys.objects AS o
INNER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
INNER JOIN sys.partitions AS p
ON o.[object_id] = p.[object_id]
INNER JOIN sys.indexes AS i
ON p.[object_id] = i.[object_id]
AND p.index_id = i.index_id
INNER JOIN sys.data_spaces AS ds
ON i.data_space_id = ds.data_space_id
INNER JOIN sys.partition_schemes AS ps
ON ds.data_space_id = ps.data_space_id
INNER JOIN sys.partition_functions AS pf
ON ps.function_id = pf.function_id
LEFT OUTER JOIN sys.partition_range_values AS prv
ON pf.function_id = prv.function_id
AND p.partition_number = prv.boundary_id
LEFT OUTER JOIN sys.destination_data_spaces AS dds
ON ps.data_space_id = dds.partition_scheme_id
AND p.partition_number = dds.destination_id
LEFT OUTER JOIN sys.data_spaces AS ds2
ON dds.data_space_id = ds2.data_space_id
ORDER BY
DatabaseName
,SchemaName
,TableName
,IndexName
,PartitionNumber
--=================================================================================
-- SECTION 2 - SWITCH OUT
-- 001 - Create TestTableOut
-- 002 - Switch out partition in range 0-14
-- 003 - Merge range 0 -29
-- 001. TestTableOut
:SETVAR TableName "TestTable"
IF OBJECT_ID('dbo.$(TableName)Out') IS NOT NULL
DROP TABLE [dbo].[$(TableName)Out]
CREATE TABLE [dbo].[$(TableName)Out](
[Partition_PK] [int] NOT NULL,
[GUID_PK] [uniqueidentifier] NOT NULL,
[CreateDate] [datetime] NULL,
[CreateServer] [nvarchar](50) NULL,
[RandomNbr] [int] NULL,
CONSTRAINT [PK_$(TableName)Out] PRIMARY KEY CLUSTERED
[Partition_PK] ASC,
[GUID_PK] ASC
) ON $(TableName)_fg2;
GO
-- 002 - Switch out partition in range 0-14
--:SETVAR TableName "TestTable"
ALTER TABLE dbo.$(TableName)
SWITCH PARTITION 2 TO dbo.$(TableName)Out;
-- 003 - Merge range 0 - 29
--:SETVAR TableName "TestTable"
ALTER PARTITION FUNCTION $(TableName)_func()
MERGE RANGE (15);
-- Confirm table partitioning
-- Original source of this query - http://lextonr.wordpress.com/tag/sys-destination_data_spaces/
SELECT
N'DatabaseName' = DB_NAME()
, N'SchemaName' = s.name
, N'TableName' = o.name
, N'IndexName' = i.name
, N'IndexType' = i.type_desc
, N'PartitionScheme' = ps.name
, N'DataSpaceName' = ds.name
, N'DataSpaceType' = ds.type_desc
, N'PartitionFunction' = pf.name
, N'PartitionNumber' = dds.destination_id
, N'BoundaryValue' = prv.value
, N'RightBoundary' = pf.boundary_value_on_right
, N'PartitionFileGroup' = ds2.name
, N'RowsOfData' = p.[rows]
FROM
sys.objects AS o
INNER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
INNER JOIN sys.partitions AS p
ON o.[object_id] = p.[object_id]
INNER JOIN sys.indexes AS i
ON p.[object_id] = i.[object_id]
AND p.index_id = i.index_id
INNER JOIN sys.data_spaces AS ds
ON i.data_space_id = ds.data_space_id
INNER JOIN sys.partition_schemes AS ps
ON ds.data_space_id = ps.data_space_id
INNER JOIN sys.partition_functions AS pf
ON ps.function_id = pf.function_id
LEFT OUTER JOIN sys.partition_range_values AS prv
ON pf.function_id = prv.function_id
AND p.partition_number = prv.boundary_id
LEFT OUTER JOIN sys.destination_data_spaces AS dds
ON ps.data_space_id = dds.partition_scheme_id
AND p.partition_number = dds.destination_id
LEFT OUTER JOIN sys.data_spaces AS ds2
ON dds.data_space_id = ds2.data_space_id
ORDER BY
DatabaseName
,SchemaName
,TableName
,IndexName
,PartitionNumber
The table below shows the results of the ‘Confirm Table Partitioning’ query, before and after the MERGE.
The T-SQL code below illustrates the problem.
-- PartitionLab_RangeRight
USE workspace;
DROP TABLE dbo.TestTableOut;
USE master;
ALTER DATABASE workspace
REMOVE FILE TestTable_f3 ;
-- ERROR
--Msg 5042, Level 16, State 1, Line 1
--The file 'TestTable_f3 ' cannot be removed because it is not empty.
ALTER DATABASE workspace
REMOVE FILE TestTable_f2 ;
-- Works surprisingly!!
use workspace;
ALTER INDEX [PK_TestTable] ON [dbo].[TestTable] REBUILD PARTITION = 2;
--Msg 622, Level 16, State 3, Line 2
--The filegroup "TestTable_fg2" has no files assigned to it. Tables, indexes, text columns, ntext columns, and image columns cannot be populated on this filegroup until a file is added.
--The statement has been terminated.
If you run ALTER INDEX REBUILD before trying to remove files from File Group 3, it works. Rerun the database setup script then the code below.
-- RANGE RIGHT
-- Rerun PartitionLabSetup_RangeRight.sql before the code below
USE workspace;
DROP TABLE dbo.TestTableOut;
ALTER INDEX [PK_TestTable] ON [dbo].[TestTable] REBUILD PARTITION = 2;
USE master;
ALTER DATABASE workspace
REMOVE FILE TestTable_f3;
-- Works as expected!!
The file in File Group 2 appears to contain data but it can be dropped. Although the system views are reporting the data in File Group 2, it still physically resides in File Group 3 and isn’t moved until the index is rebuilt. The RANGE RIGHT function means
the left file group (File Group 2) is retained when splitting ranges.
RANGE LEFT would have retained the data in File Group 3 where it already resided, no INDEX REBUILD is necessary to effectively complete the MERGE operation. The script below implements the same partitioning strategy (data distribution between partitions)
on the test table but uses different boundary definitions and RANGE LEFT.
--=================================================================================
-- PartitionLabSetup_RangeLeft.sql
-- 001. Create test database
-- 002. Add file groups and files
-- 003. Create partition function and schema
-- 004. Create and populate a test table
--=================================================================================
USE [master]
GO
-- 001 - Create Test Database
:SETVAR DataDrive "D:\SQL\Data\"
:SETVAR LogDrive "D:\SQL\Logs\"
:SETVAR DatabaseName "workspace"
:SETVAR TableName "TestTable"
-- Drop if exists and create Database
IF DATABASEPROPERTYEX(N'$(databasename)','Status') IS NOT NULL
BEGIN
ALTER DATABASE $(DatabaseName) SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DROP DATABASE $(DatabaseName)
END
CREATE DATABASE $(DatabaseName)
ON
( NAME = $(DatabaseName)_data,
FILENAME = N'$(DataDrive)$(DatabaseName)_data.mdf',
SIZE = 10,
MAXSIZE = 500,
FILEGROWTH = 5 )
LOG ON
( NAME = $(DatabaseName)_log,
FILENAME = N'$(LogDrive)$(DatabaseName).ldf',
SIZE = 5MB,
MAXSIZE = 5000MB,
FILEGROWTH = 5MB ) ;
GO
-- 002. Add file groups and files
--:SETVAR DatabaseName "workspace"
--:SETVAR TableName "TestTable"
--:SETVAR DataDrive "D:\SQL\Data\"
--:SETVAR LogDrive "D:\SQL\Logs\"
DECLARE @nSQL NVARCHAR(2000) ;
DECLARE @x INT = 1;
WHILE @x <= 6
BEGIN
SELECT @nSQL =
'ALTER DATABASE $(DatabaseName)
ADD FILEGROUP $(TableName)_fg' + RTRIM(CAST(@x AS CHAR(5))) + ';
ALTER DATABASE $(DatabaseName)
ADD FILE
NAME= ''$(TableName)_f' + CAST(@x AS CHAR(5)) + ''',
FILENAME = ''$(DataDrive)\$(TableName)_f' + RTRIM(CAST(@x AS CHAR(5))) + '.ndf''
TO FILEGROUP $(TableName)_fg' + RTRIM(CAST(@x AS CHAR(5))) + ';'
EXEC sp_executeSQL @nSQL;
SET @x = @x + 1;
END
-- 003. Create partition function and schema
--:SETVAR TableName "TestTable"
--:SETVAR DatabaseName "workspace"
USE $(DatabaseName);
CREATE PARTITION FUNCTION $(TableName)_func (int)
AS RANGE LEFT FOR VALUES
-1,
14,
29,
44,
59
CREATE PARTITION SCHEME $(TableName)_scheme
AS
PARTITION $(TableName)_func
TO
$(TableName)_fg1,
$(TableName)_fg2,
$(TableName)_fg3,
$(TableName)_fg4,
$(TableName)_fg5,
$(TableName)_fg6
-- Create TestTable
--:SETVAR TableName "TestTable"
--:SETVAR BackupDrive "D:\SQL\Backups\"
--:SETVAR DatabaseName "workspace"
CREATE TABLE [dbo].$(TableName)(
[Partition_PK] [int] NOT NULL,
[GUID_PK] [uniqueidentifier] NOT NULL,
[CreateDate] [datetime] NULL,
[CreateServer] [nvarchar](50) NULL,
[RandomNbr] [int] NULL,
CONSTRAINT [PK_$(TableName)] PRIMARY KEY CLUSTERED
[Partition_PK] ASC,
[GUID_PK] ASC
) ON $(TableName)_scheme(Partition_PK)
) ON $(TableName)_scheme(Partition_PK)
ALTER TABLE [dbo].$(TableName) ADD CONSTRAINT [DF_$(TableName)_GUID_PK] DEFAULT (newid()) FOR [GUID_PK]
ALTER TABLE [dbo].$(TableName) ADD CONSTRAINT [DF_$(TableName)_CreateDate] DEFAULT (getdate()) FOR [CreateDate]
ALTER TABLE [dbo].$(TableName) ADD CONSTRAINT [DF_$(TableName)_CreateServer] DEFAULT (@@servername) FOR [CreateServer]
-- 004. Create and populate a test table
-- Load TestTable Data - Seconds 0-59 are used as the Partitoning Key
--:SETVAR TableName "TestTable"
SET NOCOUNT ON;
DECLARE @Now DATETIME = GETDATE()
WHILE @Now > DATEADD(minute,-1,GETDATE())
BEGIN
INSERT INTO [dbo].$(TableName)
([Partition_PK]
,[RandomNbr])
VALUES
DATEPART(second,GETDATE())
,ROUND((RAND() * 100),0)
END
-- Confirm table partitioning - http://lextonr.wordpress.com/tag/sys-destination_data_spaces/
SELECT
N'DatabaseName' = DB_NAME()
, N'SchemaName' = s.name
, N'TableName' = o.name
, N'IndexName' = i.name
, N'IndexType' = i.type_desc
, N'PartitionScheme' = ps.name
, N'DataSpaceName' = ds.name
, N'DataSpaceType' = ds.type_desc
, N'PartitionFunction' = pf.name
, N'PartitionNumber' = dds.destination_id
, N'BoundaryValue' = prv.value
, N'RightBoundary' = pf.boundary_value_on_right
, N'PartitionFileGroup' = ds2.name
, N'RowsOfData' = p.[rows]
FROM
sys.objects AS o
INNER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
INNER JOIN sys.partitions AS p
ON o.[object_id] = p.[object_id]
INNER JOIN sys.indexes AS i
ON p.[object_id] = i.[object_id]
AND p.index_id = i.index_id
INNER JOIN sys.data_spaces AS ds
ON i.data_space_id = ds.data_space_id
INNER JOIN sys.partition_schemes AS ps
ON ds.data_space_id = ps.data_space_id
INNER JOIN sys.partition_functions AS pf
ON ps.function_id = pf.function_id
LEFT OUTER JOIN sys.partition_range_values AS prv
ON pf.function_id = prv.function_id
AND p.partition_number = prv.boundary_id
LEFT OUTER JOIN sys.destination_data_spaces AS dds
ON ps.data_space_id = dds.partition_scheme_id
AND p.partition_number = dds.destination_id
LEFT OUTER JOIN sys.data_spaces AS ds2
ON dds.data_space_id = ds2.data_space_id
ORDER BY
DatabaseName
,SchemaName
,TableName
,IndexName
,PartitionNumber
--=================================================================================
-- SECTION 2 - SWITCH OUT
-- 001 - Create TestTableOut
-- 002 - Switch out partition in range 0-14
-- 003 - Merge range 0 -29
-- 001. TestTableOut
:SETVAR TableName "TestTable"
IF OBJECT_ID('dbo.$(TableName)Out') IS NOT NULL
DROP TABLE [dbo].[$(TableName)Out]
CREATE TABLE [dbo].[$(TableName)Out](
[Partition_PK] [int] NOT NULL,
[GUID_PK] [uniqueidentifier] NOT NULL,
[CreateDate] [datetime] NULL,
[CreateServer] [nvarchar](50) NULL,
[RandomNbr] [int] NULL,
CONSTRAINT [PK_$(TableName)Out] PRIMARY KEY CLUSTERED
[Partition_PK] ASC,
[GUID_PK] ASC
) ON $(TableName)_fg2;
GO
-- 002 - Switch out partition in range 0-14
--:SETVAR TableName "TestTable"
ALTER TABLE dbo.$(TableName)
SWITCH PARTITION 2 TO dbo.$(TableName)Out;
-- 003 - Merge range 0 - 29
:SETVAR TableName "TestTable"
ALTER PARTITION FUNCTION $(TableName)_func()
MERGE RANGE (14);
-- Confirm table partitioning
-- Original source of this query - http://lextonr.wordpress.com/tag/sys-destination_data_spaces/
SELECT
N'DatabaseName' = DB_NAME()
, N'SchemaName' = s.name
, N'TableName' = o.name
, N'IndexName' = i.name
, N'IndexType' = i.type_desc
, N'PartitionScheme' = ps.name
, N'DataSpaceName' = ds.name
, N'DataSpaceType' = ds.type_desc
, N'PartitionFunction' = pf.name
, N'PartitionNumber' = dds.destination_id
, N'BoundaryValue' = prv.value
, N'RightBoundary' = pf.boundary_value_on_right
, N'PartitionFileGroup' = ds2.name
, N'RowsOfData' = p.[rows]
FROM
sys.objects AS o
INNER JOIN sys.schemas AS s
ON o.[schema_id] = s.[schema_id]
INNER JOIN sys.partitions AS p
ON o.[object_id] = p.[object_id]
INNER JOIN sys.indexes AS i
ON p.[object_id] = i.[object_id]
AND p.index_id = i.index_id
INNER JOIN sys.data_spaces AS ds
ON i.data_space_id = ds.data_space_id
INNER JOIN sys.partition_schemes AS ps
ON ds.data_space_id = ps.data_space_id
INNER JOIN sys.partition_functions AS pf
ON ps.function_id = pf.function_id
LEFT OUTER JOIN sys.partition_range_values AS prv
ON pf.function_id = prv.function_id
AND p.partition_number = prv.boundary_id
LEFT OUTER JOIN sys.destination_data_spaces AS dds
ON ps.data_space_id = dds.partition_scheme_id
AND p.partition_number = dds.destination_id
LEFT OUTER JOIN sys.data_spaces AS ds2
ON dds.data_space_id = ds2.data_space_id
ORDER BY
DatabaseName
,SchemaName
,TableName
,IndexName
,PartitionNumber
The table below shows the results of the ‘Confirm Table Partitioning’ query, before and after the MERGE.
The data in the File and File Group to be dropped (File Group 2) has already been switched out; File Group 3 contains the data so no index rebuild is needed to move data and complete the MERGE.
RANGE RIGHT would not be a problem in a ‘Sliding Window’ if the same file group is used for all partitions, when they are created and dropped it introduces a dependency on full index rebuilds. Larger tables are typically partitioned and a full index rebuild
might be an expensive operation. I’m not sure how a RANGE RIGHT partitioning strategy could be implemented, with an ascending partitioning key, using multiple file groups without having to move data. Using a single file group (multiple files) for all partitions
within a table would avoid physically moving data between file groups; no index rebuild would be necessary to complete a MERGE and system views would accurately reflect the physical location of data.
If a RANGE RIGHT partition function is used, the data is physically in the wrong file group after the MERGE assuming a typical ascending partitioning key, and the 'Data Spaces' system views might be misleading. Thanks to Manuj and Chris for a lot of help
investigating this.
NOTE 10/03/2014 - The solution
The solution is so easy it's embarrassing, I was using the wrong boundary points for the MERGE (both RANGE LEFT & RANGE RIGHT) to get rid of historic data.
-- Wrong Boundary Point Range Right
--ALTER PARTITION FUNCTION $(TableName)_func()
--MERGE RANGE (15);
-- Wrong Boundary Point Range Left
--ALTER PARTITION FUNCTION $(TableName)_func()
--MERGE RANGE (14);
-- Correct Boundary Pounts for MERGE
ALTER PARTITION FUNCTION $(TableName)_func()
MERGE RANGE (0); -- or -1 for RANGE LEFT
The empty, switched out partition (on File Group 2) is then MERGED with the empty partition maintained at the start of the range and no data movement is necessary. I retract the suggestion that a problem exists with RANGE RIGHT Sliding Windows using multiple
file groups and apologize :-)

Hi Paul Brewer,
Thanks for your post and glad to hear that the issue is resolved. It is kind of you post a reply to share your solution. That way, other community members could benefit from your sharing.
Regards.
Sofiya Li
Sofiya Li
TechNet Community Support

AVOID Subpartition(list) to be created when Splitting Main Partition(range)

I have created a table structure as below:
CREATE TABLE TEST_SUBPARTITIONS_1
RECORD_ID INTEGER NOT NULL,
SUB_ID VARCHAR2(100),
COBDATE DATE,
DESC VARCHAR2(2000)
PARTITION BY RANGE (COBDATE)
SUBPARTITION BY list(SUB_ID)
PARTITION INITIAL_PARTITION VALUES LESS THAN (TO_DATE(' 2200-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
TABLESPACE TBS_DATA
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
(SUBPARTITION INITIAL_SUBPARTITION VALUES ('INITIAL_DUMMY_SUB_ID') TABLESPACE TBS_DATA
CREATE UNIQUE INDEX TEST_SUBPARTITIONS_1_PK ON TEST_SUBPARTITIONS_1 (COBDATE, RECORD_ID, SUB_ID) LOCAL;
ALTER TABLE TEST_SUBPARTITIONS_1 ADD CONSTRAINT TEST_SUBPARTITIONS_1_PK PRIMARY KEY (COBDATE, RECORD_ID, SUB_ID);
I am partitioning the table based on range (COBDATE) and subpartitioning based on list (SUB_ID).
The table now is created with initial partitions and initial subpartition.
We are splitting the partitions in our procedure as below
ALTER TABLE TEST_SUBPARTITIONS_1 SPLIT PARTITION
TST_SUB_R21001231 AT (TO_DATE(20130220,'YYYYMMDD') ) INTO
     (PARTITION TST_SUB_R20130219 TABLESPACE TBS_DATA, PARTITION TST_SUB_R21001231)
The partition is getting split correctly with new partition as
TST_SUB_R20130219, but the subpartition is also created automatically with some 'SYS' name.
(i.e Name: SYS_SUBP693 , Values: INITIAL_DUMMY_SUB_ID)
This happens after every split of range by COBDATE.
Here it has created as below:
Partition          SubPartition
TST_SUB_R21001231     INITIAL_SUBPARTITION
TST_SUB_R20130219     SYS_SUBP693
TST_SUB_R20130220     SYS_SUBP694
TST_SUB_R20130221     SYS_SUBP695
I want to AVOID splitting subpartition when I split the main partition
i.e a SYS subpartition should not be created when I split the partition for COBDATE.
Let me know how do I avoid this in main "alter statement" above?
Any other solution?     I do not want to drop the SYS subpartition later, instead want it to avoid creating only when I split the partition.

>
I want to AVOID splitting subpartition when I split the main partition
i.e a SYS subpartition should not be created when I split the partition for COBDATE.
Let me know how do I avoid this in main "alter statement" above?
Any other solution? I do not want to drop the SYS subpartition later, instead want it to avoid creating only when I split the partition.
>
The subpartitions aren't being split. Oracle is creating new subpartitions for the new partition. The subpartitions need to exist since that is where the data is stored.
You can avoid the SYS prefix on the name though by using a different naming convention.
See the 'Splitting a *-List Partition' section of the VLDB and Partitioning Guide
http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm#i1008028
>
The ALTER TABLE ... SPLIT PARTITION statement provides no means of specifically naming subpartitions resulting from the split of a partition in a composite partitioned table. However, for those subpartitions in the parent partition with names of the form partition name_subpartition name, the database generates corresponding names in the newly created subpartitions using the new partition names. All other subpartitions are assigned system generated names of the form SYS_SUBPn. System generated names are also assigned for the subpartitions of any partition resulting from the split for which a name is not specified. Unnamed partitions are assigned a system generated partition name of the form SYS_Pn.

Reg. table partition

Hi
Shall anyone explain about table partition.
What it is and when it can be used.
regards
Sridhar
[email protected]

Hi,
Partitioning is nothing but u can split up the whoe dataset of an Info cube into smaller, physically independant and redundancy free units. Because of this Query performance has increased while reporting, also when u r deleting data from the info cube.
We can Partition the ODS/Cube based on 0CALMONTH/0FISCYEAR.
Double click on ur ODS/Cube.
Extras > Partitioning.
This is called Physical partitioning.we go fro this partition prior loading data into the info provdider..
You can even do that after the load, but you have to move the data.
There is another Partitioning also LOGICAL PARTITIONING.
Ex: If we have 2 maintain 3 years of Data.
We will maintain 2005 data in a cube, 2006 data in a cube and 2007 data in cube.
Different cube for different years....we will group these Cubes under a Multi Provider.
Check the following link regarding partitioning:
http://help.sap.com/saphelp_nw04/helpdata/en/0a/cd6e3a30aac013e10000000a114084/frameset.htm
Partitioning

TABLE PARTITION이 존재하는 DATAFILE이 삭제된 경우 조치방법

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
SCOPE
8~10g Standard Edition 에서는 Partitioning Option 은 지원하지 않는다.
Partitioned table의 partition이 포함되어 있는 datafile이 OS level에서
삭제된 경우, 해당 datafile을 offline drop하고 open한 후 해당 table을
access하고자 하는 경우 다음과 같은 error가 유발된다.
ORA-00376: (File cannot be read at this time)
Cause: An attempt was made to read from a file that is not readable.
The most likely cause is that the file is off line.
Action: Check the state of the file.
Bring the file online, if necessary.
그리고, 해당 tablespace를 drop하고자 하면 다음과 같은 error가 유발된다.
ORA-14404: (Partitioned table contains partitions in a different
tablespace)
Cause: An attempt was made to drop a tablespace which contains
tables whose partitions are not completely contained in this
tablespace.
Action: Find tables with partitions which span the tablespace being
dropped and some other tablespace(s). Drop these tables or
move partitions to a different tablespace.
이 경우 다음과 같은 절차로 조치가능하다.
예를 들어, DEPT라는 partitioned table중에서 PART2라는 partition이 존재하는
TS_PART2의 datafile이 유실되었으며, 해당 datafile을 offline drop한 후
open 하였다고 가정한다.
1. 가장 간단하게 해당 partitioned table전체를 drop한 후 recreate한다.
a. drop table DEPT ;
b. drop tablespace TS_PART2 including contents ;
c. tablespace recreate.
d. table rebuild.
이 과정의 문제점은 전체 partitioned table을 복구해야 하므로 시간이
오래 소요된다는 것이다.
2. 해당 partition만을 drop후 재생성한다.
a. alter table DEPT drop partition PART2 ;
b. drop tablespace TS_PART2 including contents ;
c. tablespace recreate.
d. add partition or split partition.
e. 해당 partition만의 data를 reload.
partitioned table전체 data를 reload하는 것 보다 짧은 시간이 소요된다.
3. temporary table을 생성하여 exchange한다.
a. DEPT talbe과 동일한 구조의 dummy table을 다른 tablespace에 생성한다.
create table DEPT_TEMP as select * from DEPT where 1=2;
b. 이 table을 문제의 partition과 exchange한다.
alter table DEPT
exchange partition PART2 with table DEPT_TEMP
without validation ;
c. drop tablespace TS_PART2 including contents ;
d. 새로운 partition에 필요한 data를 load한다.
이때, 제 3의 table에 load한후 동일한 방법으로 exchange를 하여도
무방하다.

Problem with table partitioning

Hi,
I am facing an issue regarding table partitioning. I splitted a partition on a table and added a new one using below command:
ALTER TABLE infx.ncr_item_input SPLIT PARTITION MCS AT ('MID')
INTO (PARTITION MCS,PARTITION MID);
Later I faced some issue and dropped the partiton using below command:
alter table infx.ncr_item_input drop partition MID;
Now when I am trying to add the partiton again using the first command, I am getting error: ORA-14080: partition cannot be split along the specified high bound.
Although I had dropped the partiton and it is no more there in the table, it still exists somewhere in database and that I checked in the view dba_tab_partitions where I can see the values as:
Partiton_name High_value
MCS 'MID'
How do I resolve this issue? Can someone help please. Appreciate quick response.
Thanks,
Sonam

>
Now when I am trying to add the partiton again using the first command, I am getting error: ORA-14080: partition cannot be split along the specified high bound.
Although I had dropped the partiton and it is no more there in the table, it still exists somewhere in database and that I checked in the view dba_tab_partitions where I can see the values as:
Partiton_name High_value
MCS 'MID'
How do I resolve this issue?
>
Not easily. You can recreate the table like I show below. Or you can rename the MCS partition and add a new MCS MAXVALUE partition.
alter table split_test rename partition mcs to mcs1
alter table split_test add partition MCS values less than (maxvalue)Then you need to merge the two partitions together.
The problem you have is because you have to split partitions on a value that is IN the range of data for the partition.
The value 'MID' is now the HIGH_VALUE for the partition MCS so you can't split on it because that value isn't part of the data.
Try this samle code and you will see what is happening.
CREATE TABLE split_test (
id            NUMBER(10),
created_date DATE,
lookup_id     NUMBER(10),
data          VARCHAR2(50)
PARTITION BY RANGE (data)
(PARTITION mcs VALUES LESS THAN (MAXVALUE));
select * from user_tab_partitions where table_name = 'SPLIT_TEST'The high value for MCS is now MAXVALUE so do the split
ALTER TABLE SPLIT_TEST SPLIT PARTITION MCS AT ('MID')
INTO (PARTITION MCS,PARTITION MID);
select * from user_tab_partitions where table_name = 'SPLIT_TEST'The high value for MCS is now 'MID' and the high value for MID is now MAXVALUE.
If you drop the MID partition the high value for MCS is still 'MID' so you cannot split it on 'MID' since that isn't in the range.
Your SPLIT command should have put MID before MCS. That is, you should have used
ALTER TABLE SPLIT_TEST SPLIT PARTITION MCS AT ('MID')
INTO (PARTITION MID,PARTITION MCS);
select * from user_tab_partitions where table_name = 'SPLIT_TEST'Now the high value for MCS is still MAXVALUE and the high value for MID is 'MID; the reverse of what you had before.
Now you can drop MID and split MCS again if you needed to.
See ALTER TABLE in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2113516

ASM and table partitioning

hi gurus,
i was told by a colleague table level partitioning is not required if ASM is in place, ASM can manage load balancing etc.
your expert opinion please..
thanks in advance,
charles

Hi Charles,
Table partition and ASM are two different things.
ASM can perform load balance and manage the disks, table partitions split table to several smaller segments.
Table partitions allow partition pruning and the ability to manage data in smaller portions (such as drop or truncate an entire partition etc.). This has nothing to do with ASM and is very important advantages, regardless your disk and storage management
HTH
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]

What is table partition?

HI,
What is meant for table partition?
-Arun.M.D

Hi Arun ,
You use partitioning to split the total dataset for an InfoProvider into several, smaller, physically independent and redundancy-free units. This separation improves system performance when you analyze data delete data from the InfoProvider.The basic idea behind database partitioning is to split a physical table and its indexes into several smaller physical tables and indexes.
http://help.sap.com/saphelp_nw04s/helpdata/en/33/dc2038aa3bcd23e10000009b38f8cf/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/e0/b60b404b2b1e07e10000000a1550b0/content.htm
Regards,
®

Getting error while importing a table partition

Hi,
I am trying to import a table partition from OEM and occurred with following error:
Job IMPORT000042 has been reopened at Friday, 13 June, 2008 14:44
Restarting "SYSMAN"."IMPORT000042":
Processing object type TABLE_EXPORT/TABLE/TBL_TABLE_DATA/TABLE/TABLE_DATA
ORA-31693: Table data object "SCOTT"."CONTAINER":"PARTITION_5" failed to load/unload and is being skipped due to error:
ORA-06502: PL/SQL: numeric or value error
LPX-00210: expected '<' instead of 'n'
Job "SYSMAN"."IMPORT000042" completed with 1 error(s) at 14:44
Job state: COMPLETED
Thanks

What's the source and target database Oracle version?
What's the character set of both databases?

Index Vs table partition

I have table whose growth is 1 million per month and may increase in future. I currently place an index on column which is frequently uses in where clause. there is another column which contains months so it may possible that I make 12 partitions of that. I want to know what is suitable. is there any connection between index and table partition?
Message was edited by:
user459835

I think the question is more of what type of queries are answered by this table?
is it that most of the times the results returned span across several months?
is there any relation to the column you use in where clause with the data belonging to a particular month (or range there-of)?

Diskutil problems when trying to split mac partition

I'm having some serious issues trying to get my mac to partition properly. I think my computer hates me. Anyways, when I try to use diskutil to split my partition up into four partitions i get an odd error that I can't find anywhere online - it says "Resizing encountered error on disk disk0s2 MacOSX: Operation not supported by device (19)", the diskutil list displays:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUIDpartitionscheme *149.1 Gi disk0
1: EFI 200.0 Mi disk0s1
2: Apple_HFS MacOSX 148.6 Gi disk0s2
and the command I've run is:
sudo diskutil resizeVolume disk0s2 60G "Ext2" "Linux" 20G "NTFS" "Windows" 68G
and I've installed plugins to handle the Ext2 and NTFS formats, so I have no freaking clue what's going on, please help! Thank you very much in advance!

You have to specify the numberOfPartitions you are adding:
sudo diskutil resizeVolume disk0s2 60G 2 "Ext2" "Linux" 20G "NTFS" "Windows" 68G

How to split table in the report so it shows on the next page?

Hi,
How to split table in the report so it shows on the next page? Im trying to fit long (many columns) table into my report page. It is too long however. I want it to wrap and show the rest on the next page. What I get now is table cut at the page end and rest is not visible.

Yes, this might be that the amount of data will cause table to grow and exceed 1, 2, 3.. pages. In that case I would probably want to have, lets say , one half of columns on 1st page then the other on the 2nd page and then repeatedly the same sequence down across all pages. Is there a way to achieve this?

Slow split table export (R3load and WHERE clause)

For our split table exports, we used custom coded WHERE clauses. (Basically adding additional columns to the R3ta default column to take advantage of existing indexes).
The results have been good so far. Full tablescans have been eliminated and export times have gone down, in some cases, tables export times have improved by 50%.
However, our biggest table, CE1OC01 (120 GB), continues to be a bottleneck. Initially, after using the new WHERE clause, it looked like performance gains were dramatic, with export times for the first 5 packages dropping from 25-30 hours down to 1 1/2 hours.
However, after 2 hours, the remaining CE1OC01 split packages have shown no improvement. This is very odd because we are trying to determine why part of the table exports very fast, but other parts are running very slow.
Before the custom WHERE clauses, the export server had run into issues with SORTHEAP being exhausted, so we thought that might be the culprit. But that does not seem to be an issue now, since the improved WHERE clauses have reduced or eliminated excessive sorting.
I checked the access path of all the CE1OC01 packages, through EXPLAIN, and they all access the same index to return results. The execution time in EXPLAIN returns similar times for each of the packages:
CE1OC01-11: select * from CE1OC01 WHERE MANDT='212'
AND ("BELNR" > '0124727994') AND ("BELNR" <= '0131810250')
CE1OC01-19: select * from CE1OC01 WHERE MANDT='212'
AND ("BELNR" > '0181387534') AND ("BELNR" <= '0188469413')
      0 SELECT STATEMENT ( Estimated Costs = 8.448E+06 [timerons] )
|
---      1 RETURN
      |
      ---      2 FETCH CE1OC01
          |
          ------   3 IXSCAN CE1OC01~4 #key columns: 2
query execution time [millisec]            |       333
uow elapsed time [microsec]                |   429,907
total user CPU time [microsec]             |         0
total system cpu time [microsec]           |         0
Both queries utilize an index that has fields MANDT and BELNR. However, during R3load, CE1OC01-19 finishes in an hour and a half, whereas CE1OC01-11 can take 25-30 hours.
I am wondering if there is anything else to check on the DB2 access path side of things or if I need to start digging deeper into other aggregate load/infrastructure issues. Other tables don't seem to exhibit this behavior. There is some discrepancy between other tables' run times (for example, 2-4 hours), but those are not as dramatic as this particular table.
Another idea to test is to try and export only 5 parts of the table at a time, perhaps there is a throughput or logical limitation when all 20 of the exports are running at the same time. Or create a single column index on BELNR (default R3ta column) and see if that shows any improvement.
Anyone have any ideas on why some of the table moves fast but the rest of it moves slow?
We also notice that the "fast" parts of the table are at the very end of the table. We are wondering if perhaps the index is less fragmented in that range, a REORG or recreation of the index may do this table some good. We were hoping to squeeze as many improvements out of our export process as possible before running a full REORG on the database. This particular index (there are 5 indexes on this table) has a Cluster Ratio of 54%, so, perhaps for purposes of the export, it may make sense to REORG the table and cluster it around this particular index. By contrast, the primary key index has a Cluster Ratio of 86%.
Here is the output from our current run. The "slow" parts of the table have not completed, but they average a throughput of 0.18 MB/min, versus the "fast" parts, which average 5 MB/min, a pretty dramatic difference.
package     time      start date        end date          size MB MB/min
CE1OC01-16 10:20:37 2008-11-25 20:47 2008-11-26 07:08   417.62    0.67
CE1OC01-18   1:26:58 2008-11-25 20:47 2008-11-25 22:14   429.41    4.94
CE1OC01-17   1:26:04 2008-11-25 20:47 2008-11-25 22:13   416.38    4.84
CE1OC01-19   1:24:46 2008-11-25 20:47 2008-11-25 22:12   437.98    5.17
CE1OC01-20   1:20:51 2008-11-25 20:48 2008-11-25 22:09   435.87    5.39
CE1OC01-1    0:00:00 2008-11-25 20:48                       0.00
CE1OC01-10   0:00:00 2008-11-25 20:48                     152.25
CE1OC01-11   0:00:00 2008-11-25 20:48                     143.55
CE1OC01-12   0:00:00 2008-11-25 20:48                     145.11
CE1OC01-13   0:00:00 2008-11-25 20:48                     146.92
CE1OC01-14   0:00:00 2008-11-25 20:48                     140.00
CE1OC01-15   0:00:00 2008-11-25 20:48                     145.52
CE1OC01-2    0:00:00 2008-11-25 20:48                     184.33
CE1OC01-3    0:00:00 2008-11-25 20:48                     183.34
CE1OC01-4    0:00:00 2008-11-25 20:48                     158.62
CE1OC01-5    0:00:00 2008-11-25 20:48                     157.09
CE1OC01-6    0:00:00 2008-11-25 20:48                     150.41
CE1OC01-7    0:00:00 2008-11-25 20:48                     175.29
CE1OC01-8    0:00:00 2008-11-25 20:48                     150.55
CE1OC01-9    0:00:00 2008-11-25 20:48                     154.84

Hi all, thanks for the quick and extremely helpful answers.
Beck,
Thanks for the health check. We are exporting the entire table in parallel, so all the exports begin at the same time. Regarding the SORTHEAP, we initially thought that might be our problem, because we were running out of SORTHEAP on the source database server. Looks like for this run, and the previous run, SORTHEAP has remained available and has not overrun. That's what was so confusing, because this looked like a buffer overrun.
Ralph,
The WHERE technique you provided worked perfectly. Our export times have improved dramatically by switching to the forced full tablescan. Being always trained to eliminate full tablescans, it seems counterintuitive at first, but, given the nature of the export query, combined with the unsorted export, it now makes total sense why the tablescan works so much better.
Looks like you were right, in this case, the index adds too much additional overhead, and especially since our Cluster Ratio was terrible (in the 50% range), so the index was definitely working against us, by bouncing all over the place to pull the data out.
We're going to look at some of our other long running tables and see if this technique improves runtimes on them as well.
Thanks so much, that helped us out tremendously. We will verify the data from source to target matches up 1 for 1 by running a consistency check.
Look at the throughput difference between the previous run and the current run:
package     time       start date        end date          size MB MB/min
CE1OC01-11   40:14:47 2008-11-20 19:43 2008-11-22 11:58   437.27    0.18
CE1OC01-14   39:59:51 2008-11-20 19:43 2008-11-22 11:43   427.60    0.18
CE1OC01-12   39:58:37 2008-11-20 19:43 2008-11-22 11:42   430.66    0.18
CE1OC01-13   39:51:27 2008-11-20 19:43 2008-11-22 11:35   421.09    0.18
CE1OC01-15   39:49:50 2008-11-20 19:43 2008-11-22 11:33   426.54    0.18
CE1OC01-10   39:33:57 2008-11-20 19:43 2008-11-22 11:17   429.44    0.18
CE1OC01-8    39:27:58 2008-11-20 19:43 2008-11-22 11:11   417.62    0.18
CE1OC01-6    39:02:18 2008-11-20 19:43 2008-11-22 10:45   416.35    0.18
CE1OC01-5    38:53:09 2008-11-20 19:43 2008-11-22 10:36   413.29    0.18
CE1OC01-4    38:52:34 2008-11-20 19:43 2008-11-22 10:36   424.06    0.18
CE1OC01-9    38:48:09 2008-11-20 19:43 2008-11-22 10:31   416.89    0.18
CE1OC01-3    38:21:51 2008-11-20 19:43 2008-11-22 10:05   428.16    0.19
CE1OC01-2    36:02:27 2008-11-20 19:43 2008-11-22 07:46   409.05    0.19
CE1OC01-7    33:35:42 2008-11-20 19:43 2008-11-22 05:19   414.24    0.21
CE1OC01-16    9:33:14 2008-11-20 19:43 2008-11-21 05:16   417.62    0.73
CE1OC01-17    1:20:01 2008-11-20 19:43 2008-11-20 21:03   416.38    5.20
CE1OC01-18    1:19:29 2008-11-20 19:43 2008-11-20 21:03   429.41    5.40
CE1OC01-19    1:16:13 2008-11-20 19:44 2008-11-20 21:00   437.98    5.75
CE1OC01-20    1:14:06 2008-11-20 19:49 2008-11-20 21:03   435.87    5.88
PLPO          0:52:14 2008-11-20 19:43 2008-11-20 20:35    92.70    1.77
BCST_SR       0:05:12 2008-11-20 19:43 2008-11-20 19:48    29.39    5.65
CE1OC01-1     0:00:00 2008-11-20 19:43                       0.00
            558:13:06 2008-11-20 19:43 2008-11-22 11:58 8171.62
package     time      start date        end date          size MB   MB/min
CE1OC01-9    9:11:58 2008-12-01 20:14 2008-12-02 05:26   1172.12    2.12
CE1OC01-5    9:11:48 2008-12-01 20:14 2008-12-02 05:25   1174.64    2.13
CE1OC01-4    9:11:32 2008-12-01 20:14 2008-12-02 05:25   1174.51    2.13
CE1OC01-8    9:09:24 2008-12-01 20:14 2008-12-02 05:23   1172.49    2.13
CE1OC01-1    9:05:55 2008-12-01 20:14 2008-12-02 05:20   1188.43    2.18
CE1OC01-2    9:00:47 2008-12-01 20:14 2008-12-02 05:14   1184.52    2.19
CE1OC01-7    8:54:06 2008-12-01 20:14 2008-12-02 05:08   1173.23    2.20
CE1OC01-3    8:52:22 2008-12-01 20:14 2008-12-02 05:06   1179.91    2.22
CE1OC01-10   8:45:09 2008-12-01 20:14 2008-12-02 04:59   1171.90    2.23
CE1OC01-6    8:28:10 2008-12-01 20:14 2008-12-02 04:42   1172.46    2.31
PLPO         0:25:16 2008-12-01 20:14 2008-12-01 20:39     92.70    3.67
            90:16:27 2008-12-01 20:14 2008-12-02 05:26 11856.91

Long running table partitioning job

Dear HANA grus,
I've just finished table partitioning jobs for CDPOS(change document item) with 4 partitions by hash with 3 columns.
Total data volumn is around 340GB and the table size was 32GB !!!!!
(migration job was done without disabling CD, so currently deleting data on the table with RSCDOK99)
Before partitioning, the data volumn of the table was around 32GB.
After partitioning, the size has changed to 25GB.
It took around One and half hour with exclusive lock as mentioned in the HANA adminitration guide.
(It is QA DB, so less complaints)
I thought that I might not can do this in the production DB.
Does anyone hava any idea for accelerating this task?? (This is the fastest DBMS HANA!!!!)
Or Do you have any plan for online table partitioning functionality??(To HANA Development team)
Any comments would be appreciate.
Cheers,
- Jason

Jason,
looks like we're cross talking here...
What was your rationale to partition the table in the first place?
       => To reduce deleting time of CDPOS            (As I mentioned it was almost 10% quantity of whole Data volume, So I would like to save deleting time of the table from any pros of partitioning table like partitioning pruning)
Ok, I see where you're coming from, but did you ever try out if your idea would actually work?
As deletion of data is heavily related with locating the records to be deleted, creating an index would have probably be the better choice.
Thinking about it... you want to get rid of 10% of your data and in order to speed the overall process up, you decide to move 100% of the data into sets of 25% of the data - equally holding their 25% share of the 10% records to be deleted.
The deletion then should run along these 4 sets of 25% of data.
It's surely me, but where is the speedup potential here?
How many unloads happened during the re-partitioning?
       => It was fully uploaded in the memory before partitioning the table by myself.(from HANA studio)
I was actually asking about unloads _during_ the re-partitioning process. Check M_CS_UNLOADS for the time frame in question.
How do the now longer running SQL statements look like?
       => As i mentioned selecting/deleting increased almost twice.
That's not what I asked.
Post the SQL statement text that was taking longer.
What are the three columns you picked for partitioning?
       => mandant, objectclas, tabname(QA has 2 clients and each of them have nearly same rows of the table)
Why those? Because these are the primary key?
I wouldn't be surprised if the SQL statements only refer to e.g. MANDT and TABNAME in the WHERE clause.
In that case the partition pruning cannot work and all partitions have to be searched.
How did you come up with 4 partitions? Why not 13, 72 or 213?
       => I thought each partitions' size would be 8GB(32GB/4) if they are divided into same size(just simple thought), and 8GB size is almost same size like other largest top20 tables in the HANA DB.
Alright, so basically that was arbitrary.
For the last comment of your reply, most people would do partition for their existing large tables to get any benefit of partitioning(just like me). I think your comment can be applied for the newly inserting data.
Well, not sure what "most people" would do.
HASH partitioning a large existing table certainly is not an activity that is just triggered off in a production system. Adding partitions to a range partitions table however happens all the time.
- Lars

Splitting table partition

Similar Messages

Maybe you are looking for