db2 -extended_row_sz优点和缺点
您能帮助我了解使用 extended_row_sz 在DB2设置级别中使用的利弊吗？
我们只能为特定的表空间设置一些东西吗？
如果没有 extended_row_sz 启用启用设置，我们不允许我们创建一个总列大小超过32k的表，即我们不允许使用 varchar（5000） data类型创建。我们可以使用CLOB数据类型创建；但是，即使没有某个数据不存在，Clob也消耗了很多空间。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Extended_row_sz是针对不想花时间设计数据库以获得最佳性能的懒人。它旨在启用Oracle兼容性功能：Oracle数据库没有行尺寸限制，并且需要重写DDL的DDL，以使行大小超过页面大小确定的限制。启用扩展行尺寸后，One将能够按原样运行Oracle DDL语句。但是，DB2中的行尺寸限制没有任何地方。启用扩展行大小后发生的事情是，如果表的总声明的行宽度超过了限制，则DB2将长字符列的数据类型隐式转换为clob。这样做的情况下，如果您要明确设计表以在必要时使用clobs（LOB内线和Lob tablespace属性），则可以在没有任何性能优化的情况下进行任何性能优化。
因此，要回答您有关
extended_row_sz的优点和缺点的问题：它为您在数据库设计时间内节省了一些精力，以潜在的性能问题为代价，这不是很容易诊断，并且需要数据库重新设计无论如何，将来。extended_row_szis for lazy people who do not want to spend time designing their database for best performance. It was intended to enable the Oracle compatibility feature: the Oracle database does not have the row size limit and one would need to rewrite DDL for tables where row sizes exceeded the limit determined by the page size. After enabling the extended row size one would be able to run the Oracle DDL statements as is.However, the row size limit in Db2 did not go anywhere. What happens after enabling the extended row size is that Db2 implicitly converts the data types of long character columns to CLOB if the total declared row width of a table exceeds the limit. It does so without telling you and without any performance optimisations that a careful DBA would be able to apply if they were to explicitly design tables to use CLOBs where necessary (LOB inlining and the LOB tablespace properties come to mind).
So, to answer your question about pros and cons of
extended_row_sz: it saves you some effort at the database design time, at the cost of potential performance problems, which are not very easy to diagnose and require database redesign anyway, in the future.扩展的行大小要绕过
简而言之：DB2中的每个表行都必须物理地位于单个页面中。该页面没有存储在该页面上，仅存储在该页面中，只存储在数据页面上。群本身存储在表空间内的单独对象中。
在数据库（不是表或表空间）级别上打开了这种功能。
Extended row size is an ability to bypass the Row Size Limit (it depends on a page size) for a given table.
Briefly: each table row in Db2 must physically reside in a single page. LOBs (not inlined) are not stored in that page physically, only pointers to them are stored on data pages. LOBs itself are stored in separate objects inside tablespaces.
Such an ability is turned on at the database (not at the table or tablespace) level.