Oracle 表中的270列以上

我们正在使用oracle的11.2.0.4版本。我们有一个已经有 ~ 270列的表，我们刚刚收到开发团队的请求，添加更多的列。但是考虑到〜255列之后的行链接，我们要求团队不要添加这些新列，而是计划删除这些现有列，以便将列总数限制在〜255内。

但是开发团队问，我们能否显示一些证据，证明我们目前在该表中拥有这些附加列的开销是多少。而且我试图查看是否无论如何我们都可以将统计信息 “表fetch续行” 与数据库时间联系起来。

我确实在dba_hist_sysystat中看到，每小时AWR快照中记录了约400万个 “表获取连续行” 统计信息。但是我不确定，如何将其转换为其贡献的DB时间？那么有什么出路吗？而且我也无法将这些统计信息与任何sql_id相关联，所以想知道我们是否有一些AWR/ASH视图存储特定sql_id的统计信息 (“表获取继续行”)？

其次，我尝试手动运行查询，实际上从应用程序中执行了百万次/天。但是，当我尝试从v $ sysystat获取该会话的统计信息 “table fetch续行” 时，我看到的值为 “0”。因此，这意味着至少在当前阶段，该表没有受到 “行链” 的影响。但是，如何确保通过添加更多列来确保我们仍然安全并且不会遭受行链症状？


该表是由列CRT_DT划分的范围，并在全局级别上保留约1tb的数据，其中Num行 = 1,400,752,800，AV_ROW_LEN被称为 “236”，并且跨越约73个分区。


从TRAN_TAB中选择 * 其中ID = :B2和CRT_DT = to_date(:B1，'MM/DD/YYYY HH24:MI:SS');

计划哈希值: 2186597613

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                    |       |       |     3 (100)|          |       |       |
|   1 |  PARTITION RANGE SINGLE            |                    |     1 |   265 |     3   (0)| 00:00:01 |   KEY |   KEY |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| TRAN_TAB           |     1 |   265 |     3   (0)| 00:00:01 |   KEY |   KEY |
|   3 |    INDEX UNIQUE SCAN               | TRAN_TAB_UK        |     1 |       |     2   (0)| 00:00:01 |   KEY |   KEY |
-------------------------------------------------------------------------------------------------------------------------
复制

我看到很少有博客指出255以外的专栏问题。但仍试图将其与该数据库相关联/匹配，如果我们将来会受到此类问题的影响 (如果会增加N多列)，或者我们已经在不知不觉中受到影响。

https://jonathanlewis.wordpress.com/2018/02/28/255-columns-3/

And i was trying to see if by anyway we can relate statistics "table fetch continued row" with the database time.

我不知道将此特定状态与数据库时间联系起来的方法。您可以通过运行来评估对具有许多链式行的表的特定查询的影响:

-选择first_col
-选择last_col

并比较差异。

there is ~400million "table fetch continued row" stats getting noted in per hour

虽然这听起来确实很高，但它与其他性能指标 (如一致获得) 相比如何？

And also i am not able to associate these stats to any sql_id, so wanted to know if we have some AWR/ASH view which stores that stats("table fetch continued row") for specific sql_ids?

同样，我不知道有什么方法可以将此状态与特定SQL语句的执行联系起来，对不起。

But how to ensure that by adding couple of more columns we will still be safe and we wont suffer from row chaining symptom?

鉴于您在表中已经有270列，并且您看到了很多 “table fetch续行” 活动，因此您already患上了这个问题!

我看不到阻止请求添加更多列的好处。

尤其是你可以采取的措施来避免它可能是大量的工作:

Ensure queries only select values from position (last column - 255) onward when necessary

假设您遵循良好的编程实践，并且仅选择所需的列，这可能几乎没有区别。

如果这是not在这种情况下，将查询更改为仅访问所需的列是值得做的，而不管任何行链问题:

-它可以使优化器使用覆盖索引
-它减少了通过网络传输的数据量

Drop unnecessary columns so you get under the 255 column limit

这避免了问题，但只有当您已弃用列时才有可能。如果有，可能需要 (大量) 开发工作来从代码中删除这些列。另外，由于某种原因 (例如审计/报告)，您需要保留列的风险after你把它们掉了!

Split the table into two, each with < 255 columns

这意味着您需要将两个表连接起来以重建整个行。这很可能是slower比你在行链上的任何开销都多。此外，还增加了大量的开发工作来支持这一变化。

如果应用程序中存在性能问题，请调查这些问题。如果事实证明行链接是造成这些情况的重要原因，请开始研究避免这种情况的方法。

这是likely您还可以进行其他更改，这些更改更容易，并带来更大的性能提升。

还要注意-仅仅因为表具有> 255列并不自动意味着您有链接行。如果你，最后255列的行是链接的，所以你可以比你预期的要早得多。

https://asktom.oracle.com/pls/apex/asktom.search?tag=table-255-columns-row-chaining