仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 605|回复: 7
打印 上一主题 下一主题

[学习教程] MSSQL网页设计数据库并发处置

[复制链接]
爱飞 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:26:29 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
目前的方案是用mysqlbinlog工具,增加一个Flashback参数,输出结果为一个新的binlog文件――姑且叫做flashbacklog,这个flashbacklog顺序执行,可制定某张表和执行到哪个pos,来实现数据库的闪回。数据|数据库数据库并发处置1、并发处置
数据库的特性就是数据的会合办理和共享。在一般情形下老是有多少个事件并发地运转,这些并行的事件大概并发地存取不异的数据。因而,数据库办理体系的一个主要义务就是要有一种机制往包管这类并发的存取和修正不损坏数据的完全性,确保这些事件能准确地运转并获得准确的了局。

我们晓得,事件并发实行时若不加把持的话,将招致不准确的了局和数据库的纷歧致形态。为包管数据库数据准确地反应一切事件的更新,和在一事件修正数据时别的事件分歧时修正这个数据,数据库体系用锁来把持对数据的并发存取。
2、ORACLE的并发处置机制
无需任何申明,ORACLE主动供应行级锁,它同意用户在没有抵触的情形下更新表中分歧的行。行级锁春联机事件处置十分有效。
1、ORACLE锁
ORACLE锁的范例在一般情形下,ORACLE会主动锁住必要加锁的资本以回护数据,

这类锁是隐含的,叫隐含锁。但是,在一些前提下,这些主动的锁在实践使用时其实不能满意必要,必需野生加一些锁。这些野生加的锁叫显现锁。

上面指了然会发生隐含锁的SQL语句:

INSERT;

UPDATE;

DELETE;

DDL/DCL语句。

上面指了然会发生显现锁的SQL语句:

SELECTFORUPDATE;

LOCKTABLEINXXXMODE。

办理读的不成反复性能够用上面的办法。在ORACLE中,用SELECTFORUPDATE对预期要修正的纪录加行排它锁(X),对表加行共享锁(RS)。它经常使用于要锁住一行,但不往真的修正这一行。锁之间是有互相感化的。

比方,更新时会对表加RX锁,对行加X锁,而只要RS锁和RX锁同意再加RX锁。因而,当存在RS和RX锁时,表同意更新。再好比,当实行DDL和DCL语句时,会对表加排它锁X,而在存在X、RS、SRX、RX和S锁的条件下,都不克不及再加X锁。因而,当存在X,RS,SRX,RS或S锁时,不克不及对表做DCL和DDL操纵。如许,数据库会主动避免一个用户更新表中的数据,而其他用户在同时修正表的布局。
2、ORACLE只读事件
ORACLE撑持只读事件。只读事件有以下特性:

*在事件中只同意查询

*别的事件可修正和查询数据

*在事件中,别的用户的任何修正都看不见

只读事件的写法为:

SETTRANSACTIONREADONLY

SQL语句

COMMIT,ROLLBACK,DDL停止只读事件
3、事件分歧性的级别
事件是界说和保护分歧性的单元,封闭就是要包管这类分歧性。假如对封闭的请求高会增添开支,下降并发性和效力;有的事件其实不严厉请求了局的质量(如用于统计的事件),假如加上严厉的封闭则是不用要和不经济的。因而有需要举行进一步的剖析,考查分歧级其余分歧性对数据库数据的质量及并行才能的影响。

分歧性级别界说为以下的几个前提:

1)事件不修正别的任何事件的脏数据。脏数据是被别的事件修正过,但还没有提交的数据。

2)在事件停止前不合错误被修正的资本解锁。

3)事件不读别的任何事件的脏数据。

4)在读前对数据加共享锁(RS)和行排它锁,直至事件停止。

*满意前提1的事件叫第0级事件。

*满意前提1和2的事件叫第1级分歧性事件。

*满意前提1、2和3的事件为2级分歧性事件。

ORACLE的读分歧性包管了事件不读别的事件的脏数据。

*满意前提1、2、3和4的事件叫第3级分歧性事件。

由ORACLE的三本性质:主动加隐式锁、在事件停止时开释锁和读分歧性,使ORACLE成为主动满意以上的0、1和2级分歧性事件。因而,ORACLE主动避免了脏读(写-读依附)。可是,ORACLE不克不及主动避免丧失修正(写-写依附),读的不成反复性(读-写依附),完全办理并发性中的成绩还需满意第4个前提(3级分歧性事件),这必要程序员依据实践情形编程。

办法以下:

*假如想在一段工夫内使一些数据不被别的事件改动,且在本领务内仅仅查询数据,则可用SETTRANSACTIONREADONLY语句到达这一目标。

*假如想在一事件内修正一数据,且制止丧失修正,则应在读这一数据前用SELECTFORUPDATE对该数据加锁。

*假如想在一事件内读一数据,且想基于这一数据对别的数据修正,则应在读数据前对此数据用SELECTFORUPDATE加锁。对此品种型的使用,用这条SQL语句加锁最得当。

*假如想制止不成反复读征象,可在读前用SELECTFORUPDATE对数据加锁,或用SETTRANSACTIONREADONLY设置只读事件。
3、SYBASE的并发处置机制
SYBASE的并发处置办法与ORACLE相似,但在良多方面纷歧样。SYBASE有两种粒度的封闭,一种的粒度是页,另外一种的粒度是表。SYBASE依据SQL语句的情形决意用页封闭仍是用表封闭。
1、页级锁
页级锁有以下所始的三类:

*SHARED:在读操纵时加共享锁。在缺省形态下,在读操纵完成后开释共享锁。

*EXCLUSIVE:在更新操纵时加排它锁。在缺省形态下,在事件完成后开释排它锁。

*UPDATE:在修正和删除操纵的早期(读到被修正或删除的页时)加修正锁。在表上加了修正锁以后,还能够再加共享锁,但不克不及再加修正和排它锁。在举行修正和删除操纵时,假如没有共享锁存在,修正锁则转化为排它锁。此锁的目标是为了避免逝世锁。SYBASE仅当在WHERE子句中包括索引列时才会利用页级的排它锁和修正锁。
2、表级锁
表级锁有以下所示的三类:

*INTENT:当表中存在页级的排它锁和共享锁时,在表上加意向锁。在一切的页级锁开释后,意向锁跟着开释。

*SHARED:在读操纵时加共享锁。在缺省形态下,在读操纵完成后开释共享锁。

*EXCLUSIVE:在更新操纵时加排它锁。在缺省形态下,在事件完成后开释排它锁。
3、哀求锁
哀求锁用以避免共享锁一个接一个无停止地加在表上,从而写事件(要加排它锁)没法举行。
4、SYBASE的封闭级别
在SYBASE依据ANSI尺度界说事件的封闭级别:

(1)级别1:脏读

(2)(2)级别2:不成反复读

(3)(3)光标带来确当前值凌乱

(4)SYBASE的缺省分歧性级别为1。

假如要到达分歧性级别2和3,必需利用HOLDLOCK关头字把共享锁延续到事件的停止。办法以下:

SELECT*FROMAUTHSHOLDLOCK

WHEREAUTHOR_CODE=A00001

SYBASE还能够经由过程T-SQL的SET命令改动SYBASE的分歧性级别,从而使SYBASE主动在SELECT语句中加HOLDLOCK关头字:

SETTRANSACTIONISOLATIONLEVEL3
5、在SYBASE中进步并发效力的办法
*制止在表中特定的页上多个用户过量的封闭。

*制止在人机交互的使用中界说事件,如许会使某个用户长工夫封闭

住表(如往接德律风),使其他用户延续守候。

*使事件只管的短。

*仅当需要时才利用HOLDLOCK关头字。

 


  Mysql的存储引擎接口定义良好。有兴趣的开发者可以通过阅读文档编写自己的存储引擎。
飘灵儿 该用户已被删除
沙发
发表于 2015-1-19 12:24:26 | 只看该作者
是否碎片会引发效率问题?这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。
老尸 该用户已被删除
板凳
发表于 2015-1-25 11:25:34 | 只看该作者
但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。
冷月葬花魂 该用户已被删除
地板
发表于 2015-2-2 21:56:16 | 只看该作者
而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~
爱飞 该用户已被删除
5#
 楼主| 发表于 2015-2-8 08:12:43 | 只看该作者
索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。
飘飘悠悠 该用户已被删除
6#
发表于 2015-2-25 02:34:13 | 只看该作者
然后最好有实践机会,能够把实践到的和实践结合起来,其实理论思考是个非常困扰和痛苦的事情
若相依 该用户已被删除
7#
发表于 2015-3-15 09:34:13 | 只看该作者
呵呵,这就是偶想说的
精灵巫婆 该用户已被删除
8#
发表于 2015-3-21 23:28:49 | 只看该作者
相信各位对数据库和怎么样学习数据库都有一些经验和看法,也会有人走了一些弯路总结出自己的经验来,希望大家能把各自的看法和经验拿出来分享,给别人一份帮助,给自己一份快乐
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-22 23:36

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表