搜索
01-建表一、目的明确建表操作的风险及标准流程，最大限度避免建表操作带来的故障。二、适用范围l项目预发布新建表l项目正式发布新建表l不包含数据订正所建临时表l不包含导数据所建的中间表三、风险评估l登录到错误的schema下，导致表建到错误的schema里，而应用无法访问。l忽略了TABLESPACE参数，导致表建到了默认表空间，导致后续空间增长和维护困难。l对于未来增量较快的表选择了一个空间规划不足的表空间，导致后续空间增长和维护困难。l脚本末尾缺少分号，导致该表没有被创建上，而执行DDL的过程又不会报错。l其他原因漏建了表，导致应用访问错误。l所建的表定义（表名、字段名、字段定义、字段个数、字段顺序）跟测试环境不一致，导致应用访问错误。l同步库没有及时创建相应的表，或者没有更新同步配置，导致同步及应用出问题。四、操作流程1.准备工作a)在项目需求分析阶段，跟数据库设计人员一起明确新表所存放的数据库。具体设计原则本文不繁述。b)准备发布脚本时，检查tablespace定义，检查tablespace剩余空间，参考表空间自身负荷及新表的预期负荷，为每个新建的表选择合适的表空间，并在建表语句中添加tablespace的配置。c)定发布计划时，跟开发接口人一起商定好建表操作的时间点。如小需求没有发布计划评审，则必须在提交测试时（即表结构冻结时）即开始与开发接口人确定建表时间点。如果发生计划外的发布建表需求，则要追究项目跟进的应用DBA沟通不力的责任。d)以目前的认知，仅建表操作本身不会对数据库造成任何风险，故操作的时间点可以放宽：在变更时间窗口内，均可以执行建表操作。e)建表操作属于预授权变更，在做之前必须在ITIL中提交相应的变更申请。2.执行过程a)用应用账户登录数据库，SHOWUSER检查是否连接到正确的schema。严禁使用sys、system等用户建表。b)执行建表脚本。若一次建表个数超过三个以上，要求将脚本事先保存为文本文件，上传至数据库服务器，执行时使用@create_table_ddl.sql的方式直接执行。c)查看过程若无报错，退出当前登录。若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。3.验证方案a)常规检查：@dbcheckb)检查表定义是否与测试库一致：execpkg_check.CompareObject(’user‘,’TABLE_NAME‘);c)立即联系开发接口人进行应用测试，【建表】变更是否成功以应用测试结果为准。d)同步库若建表，也需要执行a)和b)两个步骤。02-数据订正一、目的明确【数据订正】操作的种类、风险，并根据各种类型的数据订正制定完善的步骤和回退方案，最大限度减少此类操作带来的故障。二、适用范围l新建表数据初始化l现有表新增数据l现有表删除数据l现有表上新增字段初始化l现有表上现有字段值修改三、风险评估l业务风险：订正本身所包含的业务不正确，导致给客户给公司带来损失。l程序风险：订正本身业务正确，但是应用程序无法兼容订正的数据，导致应用出错。l数据库风险：订正本身业务正确，应用程序也可以兼容，但是订正速度过快、订正并发压力过大，导致数据库无法正常提供服务。通常会造成表空间耗尽、undo消耗过快、archive增长过快、备库恢复压力大等问题。l沟通风险：在业务方-开发接口人-DBA三方的沟通交流过程中，信息传递错误或者不及时，导致最终订正的数据没有达到预期的目的。l回滚风险：主要是因为业务方的原因，订正完成一段时间后要求回退，若在订正前没有备份原始数据，则可能导致无法顺利回退或者回退难度极大，给客户给公司带来损失。l同步风险：各类同步架构下，数据订正可能导致同步堆积和同步延时，影响正常同步业务，所以有些大规模订正必须要正确屏蔽同步，并在多个库分别执行相同的订正脚本。l缓存：有些表在应用层面做了缓存，制定订正计划的时候要考虑到订正后是否需要更新缓存。四、操作流程1.准备工作a)需求分析阶段确认项目涉及的数据订正范围和数据量。b)跟开发人员确定订正后是否涉及到对缓存的刷新和订正。c)根据数据量评估对数据同步的影响，决定是否屏蔽同步。（应用DBA必须熟悉同步采用的技术、正常情况下的同步量和延时、可以容忍的同步延时、屏蔽同步的具体方法。）d)注意规划订正速度，以防undo消耗殆尽。e)订正脚本：i.开发接口人直接提供可执行的SQL脚本，DBA只负责拷贝执行。ii.开发接口人提供主键及更新字段新值列表，由DBA导入数据库，写SQL脚本关联原表批量订正。iii.开发接口人提供订正逻辑，由DBA翻译为批量提交SQL脚本。iv.订正脚本要求可断点续跑，可反复执行。v.严禁仅用一个事务来处理大规模订正（影响的记录数超过1万笔）。超过一万笔的订正必须分段提交。vi.确认订正脚本的执行计划正确。vii.脚本中加入“进度报告”，即调用如下包（但是对于trigger中判断client_info的不允许这样处理。）：Dbms_Application_Info.set_client_info(n||‘rowscommit.’);–n为变量，累加，表示当前订正的总记录数。f)开发阶段跟开发接口人确认数据订正逻辑，完成订正脚本，并跟开发接口人确认脚本是否正确，同时按照需求准备备份脚本。g)测试阶段在测试库执行订正脚本，由开发接口人和测试人员验证订正的正确性，应用DBA协助验证。h)发布前确定订正速度和并发度，确定订正时间段，预估订正总时长，若涉及量较大，需要跨天做订正，则应规划好每日订正的数据量和时间段。i)备份要求：i.新建表初始化：无需备份，回退时直接truncate即可。ii.现有表新增数据：新建备份表记录下新增记录的主键，或者在新增记录中特定字段标识区分出订正所新增的数据，回退时定向delete这些记录。iii.现有表删除数据：新建备份表记录下删除数据的完整记录，回退时直接从备份表中取出数据insert到原表。iv.现有表上新增字段初始化：无需备份，回退时将该字段update为NULL或者开发接口人要求的值。不得将删除字段作为回退手段。v.现有表上现有字段值修改：新建备份表记录下所改动记录的主键及所改动字段的原始值，回退时将改动过的字段按照主键更新到原表（若应用程序在回滚前已经修改了记录，则要根据具体业务具体分析回滚方案）。vi.备份表：备份表统一命名为table_name_bak_mmdd_operator，最后的operator为操作DBA的姓名每个字的首字母，如果超长了，则将原表名缩减。创建人有责任定期删除创建时间超过一个月以上的备份表。2.执行过程a)如果需要，按照备份脚本备份数据。b)执行订正脚本。查看订正进度，使用如下脚本：selectclient_infofromv$sessionwhereclient_infoisnotnull;–这个脚本必须配合前面描述的“进度报告”脚本执行。c)检查undo消耗:@undod)检查表空间消耗:@tbse)检查归档空间f)检查同步延时是否异常。g)如果需要刷新应用缓存，在订正结束后通知应用刷新缓存。3.验证方案a)以应用验证为主，数据库辅助做一些count等验证。以应用验证通过为操作成功标准。五、核心对象风险l考虑到对erosa和otter的影响，严禁数据订正更新主键值。六、回退方案按照备份时所做的各种不同的回退方案进行回退，回退之后也要要求应用做验证。03-创建、删除、修改sequence一、目的明确定义对于sequence对象的操作风险及步骤。二、适用范围l项目发布创建新sequence。l以删除、重建的方式修改sequence的起始值。l在线修改sequence的cache值。三、风险评估lSequence命名与应用程序中不一致，导致应用无法正常访问sequence。l双向同步的库，多库创建同名sequence，起始值和步长值设置不合理，导致生成的值在表中对应主键值同步产生冲突。l删除、重建sequence的过程中，应用无法访问sequence，高并发的应用可能会产生故障。l删除、重建sequence之后没有对sequence的权限进行恢复，导致原本访问该sequence的其他schema无法正常访问。lSequence的cache设置不合理，设置过小会导致大量的系统相关等待，反之则导致sequence生成值断层过多浪费严重。lJava程序的int16数据类型只能容纳最大21亿，所以sequence不能超过这个值，如果有可能超过，需要跟开发确认。四、操作流程1.准备工作a)默认使用变更系统生成的sequence名称，如果要修改，必须跟开发人员沟通一致。b)与开发人员、项目发布负责人沟通变更时间点。对于删除、重建的操作必须明确告诉他们其间会有短暂的无法访问，如果是高并发的应用则选择在系统访问量最低的时候执行，规避风险。c)根据并发数确定cache值，默认为100，如遇特殊需求，酌情调整。d)删除、重建的操作，事先检查是否有其他schema拥有对于该sequence的访问权限：SELECTgrantee,owner,table_name,privilegeFROMdba_tab_privsWHEREtable_name=upper(’重建的对象名‘);e)全面考虑同步的风险，确定同步环节中各个数据库的同名sequence起始值及步长，保证不会发生冲突，通常有如下两种做法：i.起始值相差不大，步长值等于数据库个数。以双库同步为例，起始值分别设为1和2，步长均设为2。ii.起始值相距较大，步长值相同。以双库同步为例，A库起始值设为1，B库起始值设为2亿，步长均设为1。相差的值可以根据增长预期进行调整。2.执行过程a)标准新建脚本：CREATESEQUENCEseq_tablenameSTARTWITH1CACHE100;命名规范：seq_tablename默认不指定recycle和maxvalue。b)标准重建脚本：DROPSEQUENCEseq_tablename;CREATESEQUENCEseq_tablenameSTARTWITH1CACHE100;为了尽量缩短sequence不可用时间，这两个语句一起放在SecureCRT的chartWindow中一起执行。c)标准修改cache脚本：ALTERSEQUENCEseq_tablenameCACHE200;d)标准赋权脚本：GRANTSELECTONseq_tablenametousername;3.验证方案a)@dbcheck检查是否有失效对象b)通知应用验证是否可以正常访问sequence五、核心对象风险高并发对象重建时短暂不可访问；04_增加、删除唯一约束一、目的明确增删唯一约束操作的风险及标准流程，最大限度避免增删唯一约束操作带来的故障。二、适用范围l项目发布新建表的增删唯一约束l对于旧表的增删唯一约束三、风险评估l对现有表新增唯一约束的操作，会堵塞包括查询在内的所有操作，风险很大，请谨慎使用，尽量在新建表时和开发讨论后增加。l没有指定index,系统自动创建了index，删除约束时，自动创建的index同时删除了。l在高峰期创建,导致大量的librarycachelock/pin的等待l有同步的应用，先要在源端加，后在目标端加。l表里有重复的数据，导致操作失败。四、操作流程1.准备工作a)检查唯一建字段上是否存在index。没有的话,需首先创建index(步骤详见增加index手册)。b)检查唯一键上是否有重复数据，如有，需和开发讨论如何处理。c)根据应用的需求和数据库的负载情况，确定操作的时间点。对于数据量和访问量较大的表，变更时间点要谨慎选择.d)检查字段上是否已经有了约束。e)增加和删除唯一约束属于标准变更，需要开发在ITIL中提交事件单，应用dba提交变更单，有技术经理审批后执行。f)对现有表新增约束，如果使用validate这个参数，会导致该表上连查询在内的所有操作都被锁住，风险非常大；如果使用novalidate参数，这个参数会导致数据字