Usually, concurrency is the criterion driving a change from allpages to datarows locking scheme. But the change is not neutral to the performance. This is because the change involves a complete restructure of the internals of data pages and index pages. The change is the most dramatic when the table has a clustered index. In an allpages table (APL), the clustered index enforces strict clustering in the sense that any new row must be placed in its corresponding page, close to the nearest keys. And also, the clustered index is more compact since the "leaf" level of pages are the data pages themselves, thus leading to a smaller index (smaller if not counting data pages space) The net result might be a performance gain or a lose, it depends.
Among the possible benefits of a change from allpages to datarows:
- Better concurrency; that is, less waits on locks. Indirectly, less deadlocks. As a particular case, deadlocks where one of the processes was inserting a row are completely eliminated.
- Although allpages clustered indexes had clear advantages which I will cover in the next section, they have also some disadvantages. Such disadvantages of the allpages clustered ix become datarows benefits. One is cheaper inserts if they tend to cause index splits in allpages; this happen when an insert goes into an already full page, then ASE has to split the page in two in order to make room for the new row.
- A possible advantage of a clustered index in a datarows table is that it allows for covered searches; that is, wide range searches which read many rows but don't require access to data pages because index columns contain the required info, so only index leaf pages are read. Not possible in APL since leaf pages are the real data.
- Possibility of using REORG REBUILD. There are some operations only supported for datarows (or datapages) tables but not allpages. REORG REBUILD is the most important of them, IMHO.
But beware of these possible disadvantages, most of them caused by the big difference in clustered index internals:
- Data is "better clustered" in allpages tables in terms of the columns of the clustered index. As a consequence, range queries (queries traversing the clustered index but retrieving many rows) may perform better in APL since the rows might be stored in fewer pages. In a disorganized datarows table, the rows might be scattered in many pages (poor clustering) A typical range query is one selecting one value for the leftmosts columns of the index but not for the other index columns; for example, WHERE A=value when the index is declared on columns A, B, C.
- A consequence of the above, the optimizer might disregard a clustered index access in this case for a datarows table.
- For complex queries, the estimates made by the optimizer are heavily influenced by the fact that the table is allpages or datarows. Although in most cases it takes the best decision, sometimes it chooses a poorly performant access plan. IMHO, this is the most daunting possibility when moving from APL to datarows in existing applications, as it might cause a sudden lose of performance for some queries.
- Need to reorganize more frequently. Luckily, it is simpler with REORG REBUILD.
Regards,
Mariano Corral Herranz