实时问题:Oracle 性能调优(类型/索引/plsql/查询)
我正在寻找实时解决方案...
以下是我的数据库列。我用的是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
提前致谢...请告诉我以防万一任何混乱...
I am looking for a real time solution...
Below are my DB columns. I am using Oracle10g. Please help me in defining table types / indexes and tuned PLSQL / query (both) for the updates and insertion
Insert and Update queries are simple but here we need to take care of the performance because my system will execute such 200 times per second.
Let me know... should I use procedures or simple queries? It is requested to write tuned plsql and query with proper DB table types / indexes.
I would really like to see the performance of my system after continuous 200 updates per second
DB table (columns) (I can change the structure if required so please let me know...)
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
Thanks in advance ... let me know in case of any confusion...
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你并没有真正给出关于你正在更新的内容等的很多细节。
作为你编写更新语句的基础,不要使用PL/SQL,除非你无法实现你想要在SQL中做的上下文切换在您开始处理任何记录之前,独自一人会损害您的表现。
如果您能够专门为更新创建索引,则对将出现在更新语句的
WHERE
子句中的列建立索引,以便在更新之前可以快速找到记录。至于插入,请查找插入记录的
/*+append */
提示的好处,看看它是否对您的特定情况有利。最后,您将使用的表结构将取决于您甚至还没有开始接触您提供的详细信息的可能因素,我建议您要么对数据库结构进行一些研究,要么向您的 DBA 询问 101 课程它。
祝你好运...
编辑:
回应:
播放 ID - ID(这里 id 是歌曲名称,例如 abc.wav 之类的东西..所以可能是 VARCHAR2,但尚未决定..您的开放方式是什么...如果主键是 VARCHAR2 类型,那可以吗... .非常欢迎任何建议......)类型 - 歌曲或消息(varchar2) 计数 - 总播放次数的总和(整数) 重试 - 总播放次数的总和(如果失败)。 ( 整数) 持续时间 - 总持续时间 ( 整数) 上次更新 - 最新更新日期时间 ( DateTime )
将 PRIMARY KEY 作为 VARCHAR2 数据类型并没有什么问题(尽管经常存在关于拥有 PRIMARY KEY 的价值的争论)非特异性PK,即序列)。但是,您必须确保您的 PK 是唯一的,如果您不能保证这一点,那么值得使用一个序列作为您的 PK,而不是引入另一个列来保持唯一性。
至于将表列声明为 INTEGER,无论如何它们最终都会被解析为 NUMBER,因此我只需将表列创建为数字(除非您有非常具体的原因将它们创建为 INTEGER)。
最后,DATETIME 列,您只需将其声明为 DATE 数据类型,除非您需要时间部分的真正精度,在这种情况下将其声明为 TIMESTAMP 数据类型。
至于帮助您了解表本身的结构(即您想要哪些列等),那么我无法帮助您,因为我对您的报告要求、应用程序要求或审计要求、公司最佳实践、命名一无所知恐怕这是你自己决定的事情。
不过,为了提高性能,请将索引保持在最小值(即,仅索引有助于 UPDATE WHERE 子句搜索的列),仅更新尽可能少的数据,并且如前所述,研究插入的 APPEND 提示,它可能对您的情况有所帮助,但您必须亲自测试一下。
You've not really given a lot of detail about WHAT you are updating etc.
As a basis for you to write your update statements, don't use PL/SQL unless you cannot achieve what you want to do in SQL as the context switching alone will hurt your performance before you even get round to processing any records.
If you are able to create indexes specifically for the update then index the columns that will appear in your update statement's
WHERE
clause so the records can be found quickly before being updated.As for inserting, look up the benefits of the
/*+ append */
hint for inserting records to see if it will benefit your particular case.Finally, the table structure you will use will depend on may factors that you haven't even begun to touch on with the details you've supplied, I suggest you either do some research on DB structure or ask your DBA's for a 101 class in it.
Best of luck...
EDIT:
In response to:
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 )
There is nothing wrong with having a PRIMARY KEY as a VARCHAR2 data type (though there is often debate about the value of having a non-specific PK, i.e. a sequence). You must, however, ensure your PK is unique, if you can't guarentee this then it would be worth having a sequence as your PK over having to introduce another columnn to maintain uniqueness.
As for declaring your table columns as INTEGER, they eventually will be resolved to NUMBER anyway so I'd just create the table column as a number (unless you have a very specific reason for creating them as INTEGER).
Finally, the DATETIME column, you only need decare it as a DATE datatype unless you need real precision in your time portion, in which case declare it as a TIMESTAMP datatype.
As for helping you with the structure of the table itself (i.e. which columns you want etc.) then that is not something I can help you with as I know nothing of your reporting requirements, application requirements or audit requirements, company best practice, naming conventions etc. I'm afraid that is something for you to decide for yourself.
For performance though, keep indexes to a minumum (i.e. only index columns that will aid your UPDATE WHERE clause search), only update the minimum data possible and, as suggested before, research the APPEND hint for inserts it may help in your case but you will have to test it for yourself.