金吊桶火烧图

正在Oracle的毗连视图长进行数据更新操做

发布时间: 2019-05-20

  (1)正在查询以往数据之前施行一下COMMIT 或ROLLBACK 操做,如许能够确保数据库的分歧性。

  现正在我们曾经正在HR.APPLICANTS表上成立起FBDA了,所有发生变化的数据将会从动保留下来,如许我们就能够向划一雇佣机遇委员会(EEOC)证明我们正在聘请人员时没有蔑视,由于我们比来和美国签定了如许一份和谈,当前我就能够拿现实数据进行申明了。

  只需正在视图中有虚拟列的存正在,只需视图中任何一列是由列表达式定义的,那么对不起,整张视图都不成以或许进行更改。这个节制道理跟这个前提是雷同的。

  以我过去30年的IT履历来看,良多时候用户、法式开辟人员以至DBA可能不经意错误地址窜了环节数据,以至物理地删除了环节表中的行,更的是,这些错误可能过了好久才被发觉,阿谁时候可能最但愿可以或许如魔法般地沉建数据,这放正在过去,只能不完全恢复数据,闪回数据当然也支撑不完全恢复,但它的粒度是数据库和指定的SCN(但前提是正在犯错前曾经了闪回日记功能),闪回表仍然受限于当前UNDO表空间UNDO保留的数量。下面给出一段代码显示若何利用闪回数据归档数据和闪回查询来找回丢失的数据的:

  所以,用户若想正在这个视图界面临员工所属的部分进行更改的话,则必然不成以或许正在SQL语句中插手Order by等排序语句。雷同的,也不成以或许正在SQL语句中含有Group by、connetc by等语句。如有这些语句的话,则数据库都不答应对数据进行数据更新操做。

  (2)闪回数据归档历程老是利用当前会话设置,包罗NLS设置如NLS_LANGUAGE和NLS_CHARACTERSET,但现实中当汗青数据被保留时,这些变量的设置可能并不婚配。

  可见,正在数据库设想的时候,就需要考虑能否需要正在视图根本上对表的内容进行更改。若需要更改的话,则必然不成以或许正在视图中采用虚拟列,而甘愿正在表中多添加一些字段。或者正在数据库视图中不采用虚拟列,而是正在前台使用法式中采用虚拟列。

  可是,并不是说合适了这个几个前提后,视图就能够畅所无阻的进行数据更新了,其仍然必需合适必然的法则。这此中,最主要的就是键值保留表法则。

  FBDA元数据:Oracle 11gR1供给了几个关于FBDA元数据的数据字典视图,包罗哪个表空间支撑可扩展的汗青数据存储,以及FBDA中保留了哪个表:

  FBDA空间办理:当一个FBDA用尽了所有可用的空间时,由这个FBDA支撑的表若是发生点窜操做时,其会话会领受到一个或两个错误动静(下面用fbda_1来注释这两个错误):

  假设现正在人事办理系统中有三个表,一个是员工根基消息表,包含员工编号(非空)、员工姓名(非空)、身份证号码等字段;第二个表是企业部分职位表包含职位编号(非空)、职位名称(非空)、职位描述等字段;第三个是员工取部分职位对应表,包含员工编号(非空)、职位编号(非空)、描述等字段。

  若用户想要正在这张视图中,更改员工所属的部分,则起首要考虑,正在生成视图的查询语句中,能否利用了Order by排序语句。如有这个排序语句的话,则正在视图长进行DML操做,是不会成功的。

  正在这个例子中,数据库办理员若成立的视图没有包含所有的非空字段。如企业部分职位表总的职位编号就没有正在这个视图中。所以,数据库不会采取这张视图上的更新。若用户确实需要正在这张视图上更新数据,则就要考虑把所有的非空字段显示正在这张视图上。

  别的,需要留意的是,无论是更新仍是删除语句,若根本表中的某个非空列不正在这个视图中,都无法进行更改。也许有人会问,若是用户不是添加记实,而只是更新数据。那莫非也要求正在视图中包含所有的非空字段呢?谜底是必定的。由于数据库系统正在提交更新事务之前就会对这个前提进行判断。

  现正在数据库办理员做了一张视图,查询员工编号、员工姓名、部分消息。此时,这张毗连视图能够用DML语句来进行更新呢?这就要看其能否满脚必然的前提。

  正在视图中,可能有些列的成果是通过列表达式定义的,正在根本表中并不存正在。我们把这些列叫做虚拟列。如正在的员工消息表中,并没有员工的出生年月消息。而正在视图中,我们能够通过身份证号码来取得某个员工的出华诞期。此时若想正在视图中更改这个出华诞期,则很较着是不可的。由于根本表中底子没有这个字段,那更改的成果就无法保留。

  数据库视图是表的一个延长对象。从理论上来说,正在视图上利用DML语句对数据进行更新,最终城市正在根本表上完成。也就是说,能够通过视图对根本表的内容进行点窜。可是,往往没有这么简单。若想正在毗连视图上施行DML点窜语句的话,需要严酷的恪守一些。不然的话,DML语句不会施行成功。

  预备一个Oracle 11g数据库利用FBDA功能是相当简单的,只需要颠末几个简单的步调即可:

  Oracle 11g正在FBDA中存储数据时没有“从头设想车轮”,每个启用FBDA的表利用三个简单的表布局,每个都以源表所有者.SYS_FBA_目标_格局定名,如表1所示。这些表中的数据能够间接查询,对于那些想一探Oracle 11g是若何办理FBDA根本布局的人来说非利用这些表不成。

  相信大部门对于保留汗青数据正在法令上的主要性都有深刻的理解,好的记账准绳要求至多保留环节财政数据达7年之久,便利国度税务机关审计。Oracle 11g将会从动删除超出保留刻日的数据,正在数据破坏期间,只针对汗青数据,而不是FBDA本身。

  此次要是由于采用了Order by排序语句后,记实的物理存储挨次发生了改变。此时,若正在视图长进行了数据更新,则其对应的根本表找不到具体更改的物理。所以,会以失败了结。

  Oracle 11g新的闪回数据归档特征让DBA有能力将汗青数据保留很是长的时间,只需保留汗青数据的表空间的容量脚够大,由于闪回查询、闪回版本查询和闪回事务查询也遭到支撑,因而Oracle DBA也能够操纵FBDA特征来改正对数据的错误点窜。FBDA安拆容易,简单,,相信它会成为Oracle DBA受欢送的东西。

  (4)为了更切确地查询FBDA中的数据,Oracle保举利用SCN,记住TIMESTAMP_TO_SCN函数能够用来间接从TIMESTAMP值中获得一个相对精确的SCN值,但它的切确度也只能达到3秒摆布。

  如这张员工取职位的对应关系表中,用户不单想晓得某个职位现有的员工有哪些;还但愿晓得,某个职位现正在员工的具体人数。要实现这个需求的话,则数据库办理员就需要正在视图中采用分组函数,来统计某个职位的具体人数。

  若想正在视图长进行数据更新操做的话,则必必要求对应根本表中的所有不答应空的字段都正在当前的视图中。其实这很好理解,若每个字段不答应为空,则又不正在当前的视图中,则新添加记实的时候,这个字段就没有被赋值,故正在保留时就会被根本表所。

  其实,这也能够通过一些矫捷的体例来避免。如正在数据库视图中不需要采用分组函数。而是正在前台的Select语句中,查用分组函数。由于前台要挪用数据库中的数据,仍然需要查用Select语句去查询视图。所以,即便正在原始的数据库视图中不合错误数据进行分组,则正在前台使用法式中仍然能够帮帮用户完成数据分组取统计的使命。此时,用户若正在视图中更改数据的话,不只能够更新数据库根本表中的内容;并且,还能够及时的反馈到前台的使用法式界面中。

  从的代码能够看出,其实利用闪回数据归档实的很简单,按照的代码,我建立一个表空间FBDA,并正在它里面建立了三个闪回数据归档:FBDA_A,FBDA_2和FBDA_3,别离保留5天,1年,7年,我还建立了一个新用户账号FBDA_ADMIN,并授予它FLASHBACK ARCHIVE ADMINISTER权限,最初,我们给系统中“sample”方案中的HR,OE和SH用户账号授予了合适的系统权限,以便它们也能够参取FBDA操做。

  除了以上几个前提之外,若需要正在视图长进行DML操做的话,则正在成立视图的Select语句中,还不成以或许有调集运算符、子查询等等。以上这些是一些必必要满脚的根基前提,缺一不成。不然的话,针对视图的DML操做,就会以失败了结。

  当UNDO表空间成功切换后,我查询SYS_FBA_HIST_73218表获取比来的UNDO事务,成果如下:

  若是毗连视图中的一个根本表的键正在他的视图中仍然存正在,而且正在毗连视图中仍然是从键,则这个根本表就为键值保留表。正在毗连视图上,对视图进行插入、删除、更新等操做时,一次只可以或许对视图中的一个键值保留表进行更新。

  可是,若视图中有这个函数的话,则也不成以或许对这张视图进行更新。这是Oracle数据库的强制。

  不管呈现哪个错误,DBA都能够手动添加FBDA的限额,或间接添加FBDA所正在表空间的大小,留意这些错误也会记实到Alert.log文件中。

  分组函数会添加数据库查询的承担;同时,使得无法正在视图上采纳DML操做。故数据库办理人员需要跟前台使用法式开辟人员进行协商,正在前台实现对数据的分组统计,而不是正在后台。

  相关链接: