【问题标题】:Real Time issues: Oracle Performance tuning (types / indexes / plsql / queries)实时问题:Oracle 性能调优(类型/索引/plsql/查询)
【发布时间】:2011-09-25 05:39:39
【问题描述】:

我正在寻找实时解决方案...

以下是我的数据库列。我正在使用Oracle10g。请帮助我定义表类型/索引并调整 PLSQL/查询(两者)以进行更新和插入

插入和更新查询很简单,但在这里我们需要注意性能,因为我的系统每秒会执行 200 次。

让我知道...我应该使用过程还是简单的查询?要求使用适当的数据库表类型/索引编写调整好的 plsql 和查询。

我真的很想看看我的系统在每秒连续更新 200 次后的性能

数据库表(列)(如果需要,我可以更改结构,所以请告诉我...)

Play ID  - ID 
Type - Song or Message
Count - Summation of total play
Retries - Summation of total play, if failed. 
Duration - Total Duration
Last Updated - Late Updated Date Time

提前致谢...如果有任何困惑请告诉我...

【问题讨论】:

  • 伙计们,正在寻找答案...请建议...
  • 您的应用程序在做什么?您是否每秒更新同一行 200 次?还是您每秒更新 200 条不同的行?您是否根据PLAY_ID 进行更新?还是基于别的东西?你真的只关心一张桌子吗?
  • 好吧,谢谢您的回复...这是信息.....What is your application doing? 在容器上部署了一个 java 应用程序名称作为 sbs。在它的顶部还有 3 个其他 java 应用程序部署了假设 A、B 和 C。现在应用程序 A、B 和 C 命中一个方法名称作为应用程序 sbs 的 Sing(id),用于播放消息。应用 sbs 的 sing(id) 方法,每秒点击 200 次左右,并为所有人播放一条消息。
  • Are you updating the same row 200 times a second? Or are you updating 200 different rows every second? - 不同的行
  • Do you update based on the PLAY_ID? Or based on something else? - 基于 play id 是的

标签: performance database-design oracle10g database-tuning


【解决方案1】:

您并没有真正提供有关您要更新的内容等的很多细节。

作为您编写更新语句的基础,除非您无法在 SQL 中实现您想要做的事情,否则不要使用 PL/SQL,因为在您开始处理任何记录之前,单独的上下文切换会损害您的性能.

如果您能够专门为更新创建索引,则对将出现在更新语句的WHERE 子句中的列进行索引,以便在更新之前快速找到记录。

至于插入,请查看 /*+ append */ 提示插入记录的好处,看看它是否对您的特定情况有益。

最后,您将使用的表结构将取决于您提供的详细信息甚至还没有开始接触的可能因素,我建议您对 DB 结构进行一些研究或向您的 DBA 询问101课在里面。

祝你好运……

编辑:

回应: Play ID - ID ( here id would be song name like abc.wav something..so may be VARCHAR2, yet not decided..whats your openion...is that fine if primary key is of type VARCHAR2....any suggesstions are most welcome...... ) Type - Song or Message ( varchar2) Count - Summation of total play ( Integer) Retries - Summation of total play, if failed. ( Integer) Duration - Total Duration ( Integer) Last Updated - Late Updated Date Time ( DateTime )

将 PRIMARY KEY 作为 VARCHAR2 数据类型并没有什么问题(尽管经常争论具有非特定 PK 的价值,即序列)。但是,您必须确保您的 PK 是唯一的,如果您不能保证这一点,那么值得将序列作为您的 PK,而不是必须引入另一个列来保持唯一性。

至于将表列声明为 INTEGER,它们最终将被解析为 NUMBER,因此我只需将表列创建为数字(除非您有非常具体的原因将它们创建为 INTEGER)。

最后,对于 DATETIME 列,您只需要将其作为 DATE 数据类型进行处理,除非您的时间部分需要真正的精度,在这种情况下将其声明为 TIMESTAMP 数据类型。

至于帮助您处理表格本身的结构(即您想要哪些列等),那我无法帮助您,因为我对您的报告要求、申请要求或审计要求一无所知,公司最好练习,命名约定等。恐怕这是您自己决定的事情。

不过,为了提高性能,将索引保持在最低限度(即仅有助于您的 UPDATE WHERE 子句搜索的索引列),仅更新可能的最少数据,并且如前所述,研究 APPEND 提示以了解它可能有助于您的插入案例,但您必须自己测试。

【讨论】:

  • 请看上面......我已经提供了所有信息......谢谢......寻找您的反馈......
  • 当您通过 PLAY_ID 更新时(并假设它是您的表的主键),那么我希望您在 PLAY_ID 列上有一个 PRIMARY KEY 索引(唯一索引),这不会既保证了表键的唯一性,又提高了更新性能。您仍然没有提供完整的表结构 - 例如列数据类型是什么?尤其是“类型”列,如果它是一个 VARCHAR2 存储歌曲/消息名称,那么这不是问题,如果它是一个 BLOB 存储实际歌曲轨道或消息...... DML 中是否引用了任何查找表?
  • Play ID - ID (这里的 id 将是歌曲名称,如 abc.wav 之类的......所以可能是 VARCHAR2,但尚未决定......你的开放是什么......如果主键是类型,那很好VARCHAR2 ....欢迎任何建议......)Type - Song or Message(varchar2)Count - Summation of total play(整数)Retries - Summation of total play, if failed.(整数)Duration - Total Duration(整数)Last Updated - Late Updated Date Time(日期时间)
  • 先生,PLz提供您宝贵的建议。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-03-20
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多