关于数据库死锁的知识外文翻译.doc

上传人:文库蛋蛋多 文档编号:2324944 上传时间:2023-02-11 格式:DOC 页数:6 大小:35.50KB
返回 下载 相关 举报
关于数据库死锁的知识外文翻译.doc_第1页
第1页 / 共6页
关于数据库死锁的知识外文翻译.doc_第2页
第2页 / 共6页
关于数据库死锁的知识外文翻译.doc_第3页
第3页 / 共6页
关于数据库死锁的知识外文翻译.doc_第4页
第4页 / 共6页
关于数据库死锁的知识外文翻译.doc_第5页
第5页 / 共6页
点击查看更多>>
资源描述

《关于数据库死锁的知识外文翻译.doc》由会员分享,可在线阅读,更多相关《关于数据库死锁的知识外文翻译.doc(6页珍藏版)》请在三一办公上搜索。

1、外文翻译About the database of the knowledge of the deadlockDatabase itself provides lock management mechanism, but from a hand, database is the client applications puppet, this is mainly because the client to the server has complete control of the gain of locks ability. The client in enquiries in the re

2、quest and the way to query processing tend to have direct control, so, if we application design reasonable enough, then appear database is normal phenomenon dead lock.Below are listed some easy to have locked application examples:A, the client cancel inquires no roll back after practice.Most of the

3、application is inquires often happens homework. However, users through the front desk the client application inquires the backend database, sometimes will cancel inquires for any variety of reasons. If the user to open the window after mouth query, because users find reflect crash or slow compelled

4、to cancel the query. But, when the client when cancel inquires, if not add rollback transaction statement, then at this time, because the user has to the server sends the inquirys request, so, the backend database involved in the table, all have been added L locked. So even if the user cancel after

5、inquires, all in the affairs for the locks within will remain. At this point, if other users need to check on the table or the user to open the window through input inquires to query conditions to improve the system response speed occurs when the jam phenomenon.Second, the client not to get all the

6、results of my query.Usually, the user will be sent to the server after queries, foreground application must be done at once extraction all the results do. If the application did not extract all the results trip, it produces a problem. For as long as the application did not withdraw promptly all the

7、results, the lock may stay at table and block other users. Since the application has been submitted to the server will SQ statements, the application must be extracted all results do. If the application does not follow the principle words (such as because at that time and no oversight configuration)

8、, cant fundamentally solve congestion.Three, inquires the execution time too long.Some inquires a relatively long time will cost. As for the query design is not reasonable or query design to watch and record it is, will make inquires the execution time lengthen. If sometimes need to Update on users

9、record or Delete operation, if the line is involved in it, you will get a lot of lock. These locks whether finally upgrade to watch the lock, can block other inquiries.So often, dont take long time running decision support search and online transaction processing inquires the mixed together.When dat

10、abase meet blocked, often need to check the application submitted to the SQL statement itself, and check and connection management, all the results do processing and other relevant application behavior. Usually, the lock for to avoid the conflict in the jam, the author has the following Suggestions.

11、Suggest a: after the completion of the extraction of all query results do.Some applications in order to improve the response speed of the user inquires, will have the option of extraction need record. The smart looks very reasonable, but, but will cause more waste. Because inquires not timely and fr

12、uit extraction of words, the lock cannot be released. When others inquires the data, will be happening.So, the author suggest in application design, database query for record to the extraction of in time. Through other means, such as adding inquires the conditions, or the way backstage inquires, to

13、improve the efficiency of the inquires. At the same time, in the application level set reasonable cache, and can also be very significantly improved query efficiency.Suggest two: in the transaction execution dont let the user input content.Although in the affairs of the process with sex, can let the

14、 user participation, in order to improve the interactivity. But, we dont recommend the database administrator tend to do so. Because if the user in affairs during the execution of the input and number, will extend the affairs of the execution time. Although people smarter, but the response speed sti

15、ll dont have a computer so fast. So, during the implementation of the user participation to let the process, will extend the affairs of waiting time. So unless there is a special needs, not in the applications execution process, reminds the user input parameters. Some affairs of the executive must p

16、arameters, best provide beforehand. If can through the variables in the parameters such as need to go in.Suggest three: make affairs as far as possible the brief.The author thinks that, database administrator should put some problem is simplified. When a need to many SQL statements to complete, migh

17、t as well take the task decomposition. At the same time, it breaks down into some brief business affairs.If the database a product information table, its record number two million. Now in a management needs, the one-time change one of the one million five hundred thousand record. If through a change

18、 affairs, the time is long. If it involves cascade update it, is time the meeting is longer.In view of this situation, we can learn affairs brief words. If the product information, may have a product type field. So in the update data, can we not one-time updates. But through the product category fie

19、lds to control, to record the iteration points. So every category of update firm consumption of time may be greatly reduces. So although operation, will need more steps. But, can effectively avoid to go to the occurrence of congestion, and improve the performance of the database.Suggest four: child

20、inquires the and list box, had better not use at the same time.Sometimes in the application of design, through the list box can really improve user input speed and accuracy, but, if foreground application does not have buffer mechanism, you often can cause congestion.As in a order management system,

21、 may need frequent input sales representatives. In order to user input convenience, sales representative often design into a list box. Every time need to input, foreground application from the background of all sales representative inquires information (if the application is not involved in the cach

22、e). On one hand, the son of nature, would be speed query slow; Second, the list box have growth time operation of the inquiry. The two parties face touch together, may cause the application of improving the running time process query. And the other user queries, such as the system administrator need

23、 to maintain customer information, and cause congestion.So, in the application design, the child inquires the best less. And the child inquires the list box and use at the same time, more need to ban. If you cant avoid it, should be in application realize caching mechanism. That way, the application

24、s need to sales representative information, will from application cache made, not every time to check the database.At the same time, can be in the list box design to search function. When there is a change to the user information, such as the system administrator to join a new sales representatives.

25、 In no again before inquires, because of their application is achieved in the cache data, so not just updated content. At this time, users will need to run to inquires the function, let the foreground application from a database query information again. This kind of design, can increase the list box

26、 and the son of the execution time inquires, effectively avoid congestion.Suggest five: in the set when cancel inquires back issues.Foreground application is designed, should allow users to a temporary change in idea, cancel the query. Such as user inquires the all product information, may feel resp

27、onse time is long, hard to bear. At this time, they will think of cancel inquires the. In this case, the application design need to design a cancel inquires the button. The user can in the process of inquires click this button cancel inquires at any time. Meanwhile, in the button affair, need to pay

28、 attention to join a rollback command. Let the database server can prompt to records or table to unlock.At the same time to the best lock or query timeout mechanism. This is largely because, sometimes also can cost a lot inquires user host to a large number of resources, and cause client crash. At t

29、his time, to be able to lock the inquires the or overtime mechanisms, namely in inquires after overtime, database server of related objects for automatic unlock. This is also the database administrator need to program developers negotiation of a problem.In addition, explicit database connection to t

30、ake control in the concurrent users, is expected to full load next use application to bear ability test, use the link, each inquires to set use inquires and lock exceeds the overtime, these methods can effectively avoid the lock conflict obstruction. When database administrators found that blocking

31、the symptoms, can from these aspect, looking for solutions.From the above analysis can see, SQL Server database lock is a double-edged sword. The security database data consistency at the same time, they will give the database caused some negative effect. How do these negative influence to the least

32、, is our database administrators task. In application design, follow the advice above, can effectively solve the problems for the lock blockages, improve the performance of the database. Visible, to basically solve congestion problem, need database management personnel and program developers work to

33、gether.中文关于数据库死锁的知识数据库本身提供了锁管理机制,但是从一方面,数据库客户端应用程序的“傀儡”,这主要是由于客户端到服务器的完全控制获得的锁的能力。客户机在请求在查询的查询处理的方法,往往有直接的控制,所以,如果我们的应用程序设计的不够合理,那么出现的数据库死锁现象就很正常了。下面列举一些容易出现锁死的应用程序例子:一、客户端取消查询后没有回滚实务。大多数应用程序查询通常发生的作业。然而,用户通过前台客户端应用程序的后端数据库查询,有时候会取消询问因为各种原因。如果用户打开窗户口查询之后,因为用户发现反映缓慢崩溃或被迫取消查询。但是,当客户端当取消问道,如果不添加回滚事务声明,

34、然后在这个时候,因为用户只有服务器发送了查询请求,因此,后端数据库中涉及的表,所有已添加L锁。因此,即使用户取消查询之后,所有的事务的锁在将继续。在这一点上,如果其他用户需要检查表或用户打开窗口来输入查询的查询条件,提高系统的响应速度时发生堵塞现象。二、客户端没有及时取得所有查询的结果.通常,用户将被发送到服务器的查询后,前台应用程序必须立刻进行提取所有的结果。如果应用程序没有旅行中提取所有的结果,它就会产生问题。只要应用程序没有及时提取所有的结果,锁可能呆在桌子和阻止其他用户。由于应用程序已被提交至服务器将平方语句,应用程序必须提取所有结果。如果应用程序没有遵循原则词(比如因为在那个时候,没

35、有监督配置),不能从根本上解决拥堵。三、查询执行时间过长。一些查询将成本的一个相对较长的时间。至于查询设计不合理或查询设计观察和记录,将使查询的执行时间延长。如果有时需要更新用户记录或删除操作,如果队伍参与着它,你会得到很多的锁。这些锁升级看是否最后锁可以阻止其他的查询。所以通常,不要把长时间运行决策支持搜索和在线事务处理,询问混合在一起。当数据库满足封锁,通常需要检查应用程序提交的SQL语句本身,并检查和连接管理,所有的结果进行处理和其他相关的应用程序行为。通常,为了避免冲突的拥塞在锁上,作者提出以下的建议。建议一:完成后提取所有查询结果。待添加的隐藏文字内容3一些应用程序为了提高用户查询的

36、响应速度,将有权选择提取需要记录。“智能”看起来很合理,但是,却会导致更大的浪费。因为没有及时的话查询结果提取、锁不能被释放。当别人查询数据,将发生阻塞的。因此,笔者建议在应用程序设计、数据库查询记录来提取时间。通过其他手段,如添加查询条件,或后台的查询时,提高查询效率。同时,在应用程序级别设置合理的缓存,也可以是非常显著提高查询效率。建议二:在事务执行时不要让用户输入内容。尽管在事务的过程性,能让用户参与,为了提高交互性。但是,我们并不推荐使用数据库管理员倾向于这么做。因为如果用户在事务执行期间输入参数,并将扩展事务的执行时间。尽管人们变得更聪明,但是响应速度仍然没有电脑,那么快。因此,在实

37、现用户的参与让这个过程中,将扩展事务的等待时间。所以除非有特殊的需求,而不是在应用程序的执行过程中,让用户输入参数。一些事务的执行必须参数,最好事先提供。如果能够通过中的变量参数如需要进去。建议三:使事务尽可能的简短。数据库管理员应该放一些问题简单化。当一个需要很多的SQL语句完成,不妨把任务分解。同时,它分解成一些简短的业务事务。如果数据库产品信息表,它记录编号二百万。现在在一个管理需求,一次性修改其中一个十亿零五十万年的纪录。如果通过改变事务的时间较长。如果涉及到级联更新它,时间会更长。鉴于这种情况,我们可以学习事务简短的话。如果产品信息,可能有一个产品类型字段。所以在更新数据,我们能不能

38、一次性更新。但通过产品类别字段来控制,来记录迭代点。所以每一类更新公司的消费时间可能会极大地降低。所以,虽然操作,将需要更多的步骤。但是,通常,可以有效地避免拥塞的发生,提高数据库的性能。建议四:子查询与列表框,最好不要同时使用。有时在应用程序设计,通过列表框真的可以改善用户输入的速度和准确性,但是,如果前台应用程序没有缓冲机制,你往往会引起交通拥堵。在一个订单管理系统,可能需要经常输入销售代表。为了方便用户输入,销售代表经常设计成一个列表框。每次需要输入,前台应用程序从背景的查询将销售代表信息(如果应用程序没有涉及缓存)。一方面,自然的孩子,将查询速度缓慢;第二,列表框有成长时间运行的查询。

39、这两方面联系在一起,可能导致应用程序提高运行的时间过程查询。和其他的用户查询,例如系统管理员需要维护客户信息,充血。所以,在应用程序设计、孩子提问最好的少。和孩子提问列表框和同时使用,更需要禁止。如果你无法避免,应该在应用程序实现缓存机制。这样,应用程序需要的销售代表的信息,将从应用程序缓存中创造出来的,而不是每次检查数据库。同时,可以在列表框设计“搜索”功能。当有一个变化给用户的信息,如系统管理员加入一个新的销售代表。在没有之前再提问,因为他们的应用程序就能实现缓存数据,所以不仅仅是更新的内容。此时,用户将需要运行查询功能,让前台应用程序从一个数据库查询信息。这种设计,可以增加列表框和儿子的

40、执行时间的查询时,有效地避免拥挤。建议五:在取消查询时设置回退事务。前台应用程序设计,应该允许用户临时改变主意,取消查询。如果用户查询所有产品的信息,可能会觉得响应时间长,难以忍受。在这段时间,他们会想到取消,问。在这种情况下,应用程序设计需要设计一个cancel按钮,问。用户可以查询过程点击该按钮取消浏览。同时,在按钮事件,需要注意加入一个回滚命令。让数据库服务器可以提示来记录或表来解锁。在同一时间或最好的锁定超时机制查询。这很大程度上是因为,有时需要花费很多的要求用户主机大量的资源,并导致客户端崩溃。这时,就可以锁定超时工作或查询机制,即在后来的要求加班,数据库服务器相关的对象自动解锁。这也是数据库管理员需要规划发展问题的谈判。此外,显式连接到并发用户控制数据库,负载预计将使用此应用程序来承受能力测试,使用了链接,每个查询和加班锁定设置使用查询加班,等等,该方法可以有效地避免阻塞锁冲突。当数据库管理员发现,阻断这些症状,能从这些方面,寻找解决方案。从上面的分析可以看到,SQL Server数据库锁是一把双刃剑。安全数据库数据一致性的同时,也将给数据库也产生了一些负面影响。如何把这些消极影响降到最低,是我们的数据库管理员的任务。在应用程序设计,遵循上面的建议,可以有效地解决这个问题锁堵塞,提高数据库的性能。可见,要从根本上解决拥堵问题,需要数据库管理人员和项目开发人员一起工作。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号