Feedback
Did this article resolve your question/issue?

   

Article

TABLEMOVE from Type I Storage Area fails with error 13517

Information

 
TitleTABLEMOVE from Type I Storage Area fails with error 13517
URL Name000045381
Article Number000164680
EnvironmentProduct: Progress
Version: 9.1x
Product: OpenEdge
Version: 10.x, 11.x
OS: All Supported Operating Systems
Question/Problem Description
TABLEMOVE from Type I Storage Area fails with error 13517.
TABLEMOVE crashes with maxarea limit on the TYPE I that data are being moved from.
TABLEMOVE operation is only moving data, not indexes.
The current high water mark for the Storage Area being moved from is within the Storage Area reserved space.
The Extend blocks in error 13517 would take the Type I Storage area over the maximum Area Blocksize.
 
Steps to Reproduce
Clarifying Information
Maximum Area-Size will be reached.
Indexes for the table being moved are in the same storage area as the table being moved.
Error MessageSYSTEM ERROR: bkxtn: Area: <areaNum> extent: <ExtentName> Attempt to exceed the maximum number of user-available blocks per area - Max: <maxAreaBlocksize> Current: <currentHiWater> Extend: <extentAmount> (13517)
example: Max: 16121855 Current: 16121823 Extend: 64 (13517) 128 RPB, 8KB blocksize.
Defect/Enhancement Number
Cause
As part of any TABLEMOVE operation, the related indexes (in this and any other Storage Area that indexes for this Table have been defined) have to be rebuilt to reflect the new rowids that this table's records now have in the new Storage Area.
 
The reason that the TABLEMOVE operation is causing the current Storage Area to extent (aka: grow and cannot extend): 
Max: 16121855 Current: 16121823 Extend: 64 (13517) 
Is because only the table is being moved to a new Storage Area, not the indexes which are also in this Storage Area.
eg: PROUTIL -C TABLEMOVE <tablename> <newStorageAreaname>
 
When building the indexes that are left in the current Storage Area, there's not enough room to extend the area as it is already near the maxarea limit for a Type I Storage Area. By the default 64 database blocks are initially needed to accommodate the rebuilding of indexes. 
 
Resolution
When needing to re-organise a database where the current Storage Area is near the maxarea limit,
move the indexes at the same time in order that there's no need to rebuild in the current area.
 
eg: PROUTIL -C TABLEMOVE <tablename> <newStorageAreaname> <newStorageAreaname2>
Where:
<newStorageAreaname>: The first storage area name specified is where the table's data will be moved.
<newStorageAreaname2>: The second storage area name specified is where the table's indexes will be moved. It can be the same area as the data or a different storage area (recommended), depending on the re-organisation design.
 
An additional consideration is that when moving indexes with the table as part of a TABLEMOVE, this will move all the related indexes to the specified Storage Area for indexes in the TABLEMOVE command. If indexes then need to be separated into distinct Storage Areas, another IDXMOVE operation will be needed. For example when the database design is such that the Primary Index is housed in the same Storage Area as the table and other indexes in a separate Storage Area.
Workaround
Notes
Last Modified Date11/20/2020 7:25 AM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.