reorg

Reclaims unused space on pages, removes row forwarding, or rewrites all rows in the table to new pages, depending on the option used.

Syntax

reorg compact table_name [partition partition_name]
	[with {resume, time = no_of_minutes, compress}]
reorg forwarded_rows table_name [partition partition_name] 
	[with {resume, time = no_of_minutes, compress}]
reorg rebuild table_name [index_name [partition index_partition_name
	[with online]]]
reorg reclaim_space table_name [index_name] [partition partition_name]
	[with {resume, time = no_of_minutes, compress}]
reorg defrag table_name [partition {partition_list}]
   [with {time = hh:mm| resume | skip_compact_extents [= pct_value]}]

Parameters

Examples

Usage

  • You cannot run reorg rebuild on system tables.

  • The table specified in reorg—excluding reorg rebuild—must have a datarows- or datapages-locking scheme.

  • Index scans traverse faster after you run reorg.

  • Running reorg against a table can have a negative effect on performance of concurrent queries.

  • If you do not include the index or partition name, the entire table is rebuilt.

  • You can perform a dump tran on a table after rebuilding its index. However, you cannot perform a dump tran if the entire table has been rebuilt.

  • Although online index rebuilding is allowed on a placement index, it rebuilds only the index pages. The data pages remain untouched, which means datarows are neither sorted nor rewritten to fresh pages. You can rebuild data pages by dropping a placement index, and then re-creating it.

  • You can rebuild the index for systabstats, but you cannot run reorg rebuild on the table itself.

  • Versions of SAP ASE earlier than 15.0 restricted you from using reorg rebuild on all-pages locked tables. SAP ASE versions 15.0 and later allow you to run reorg rebuild on entire tables that uses allpages locking. reorg rebuild rebuilds the entire table, copying the data to new sets of pages, and rebuilds all indexes.

  • You cannot use the reorg rebuild sub commands (for example, compact, reclaim_space, and forwarded_rows) on all-pages-locked tables.

  • You cannot use reorg rebuild table_name index_name or partition_name on allpages-locked tables.

  • Running reorg rebuild table_name updates the statistics for all leading index columns. However, running reorg rebuild table_name index_name does not automatically update the statistics. Instead, the SAP ASE server automatically updates index statistics when you run reorg rebuild index_name if the update includes a suffiecient change in data to affect its plan choice and performance.

  • You can run writetext concurrently with the online parameter.

  • reorg has no effect on space allocated to text or image columns.

  • You cannot issue reorg within a transaction.

  • reorg rebuild requires that you set the database option select into/bulkcopy/pllsort to true and run checkpoint in the database.

  • reorg rebuild requires additional disk space equal to the size of the table and its indexes. You can find out how much space a table currently occupies by using sp_spaceused. You can use sp_helpsegment to check the amount of space available.

  • After running reorg rebuild, you must dump the database before you can dump the transaction log.

  • Requirements for using reorg rebuild on an index are less stringent than for tables. The following rules apply:
    • You do not need to set select into to rebuild an index.

    • Rebuilding a table requires space for a complete copy of the table. Rebuilding an index works in small transactions, and deallocates pages once they are copied; therefore, the process needs space only for the pages copied on each transaction.

    • You can rebuild the index on a table while transaction level scans (dirty reads) are active.

When using reclaim_space, forwarded_rows, and compact parameters:
  • Minimize interference with other activities by using multiple small transactions of brief duration. Each transaction is limited to eight pages of reorg processing.

  • Rewrite space for a single partition.

  • Provide resume and time options that allow you to set a time limit on how long a reorg runs and to resume a reorg from the point at which the previous reorg stopped. This allows you to, for example, use a series of partial reorganizations at off-peak times to run the reorg command on a large table.

Garbage collection and locks:
  • For datarow tables – the SAP ASE server performs garbage collection using a latch, and releases the latch on a page before moving to the next page. No locks are obtained until the garbage collection encounters a forwarded row, when it acquires an exclusive table lock, which it holds until the end of that transaction. Subsequent transaction use latches until they encounter forwarded rows.

  • For data page tables – the SAP ASE server performs garbage collection using a page lock, but releases the page lock before moving to the next page. When the gargage collector encounters a forwarded row, it acquires an exclusive table lock, which it holds until the end of the transaction. Subsequent transactions use page locks until it encounters another forwarded row.

  • Use reorg compact if garbage collection encounters OAM pages that are allocated to the object, but do not refer to the allocation (running reorg compact requires a shared table lock).

The following considerations apply when using the resume and time parameters:
  • If you specify only the resume option, the reorg begins at the point where the previous reorg stopped and continues to the end of the table.

  • If you specify only the time option, the reorg starts at the beginning of the table and continues for the specified number of minutes.

  • If you specify both options, the reorg starts at the point where the previous reorg stopped and continues for the specified number of minutes.

When running reorg on compressed tables:
  • reorg rebuild – sorts the rows according to the placement index (if one exists), writing the rows to new data pages according to the space management settings currently in effect. New rows are compressed or decompressed according to individual partition’s compression level, regardless of the data compression state in the original table or partition.

  • reorg reclaim_space – compresses data rows to save more space if the table is marked for compression.

The following considerations apply when using the reorg defrag:
  • Tables must be data-only-locking (DOL) and have at least one index to use reorg defrag. Sybase recommends that the table has a unique index to efficiently accommodate the movement of the forwarded locations during reorganization.
  • You can run only one instance of reorg defrag at a time on a table.
  • When reorg defrag is in progress, DDLs cannot run on the table, for example add/drop partition, create/drop index, add/modify/drop columns. Also, other existing reorg subcommands like rebuild/reclaim/compact/forwarded rows cannot run when reorg defrag is in progress.
See also:
  • See the System Administration Guide.

  • sp_chgattribute in Reference Manual: Procedures

Standards

ANSI SQL – Compliance level: Transact-SQL extension.

Permissions

The permission checks for reorg differ based on your granular permissions settings.

SettingDescription
Enabled

With granular permissions enabled, you must be the table owner, or a user with reorg any table privilege.

Disabled

With granular permissions disabled, you must be the table owner or a user with sa_role.