阿里巴巴 数据库 标准操作手册
阿里云DataWorks（数据工场）用户指南说明书
DataWorks（数据工场）用户指南用户指南控制台阿里云数加平台管理控制台中，您可通过概览页面找到最近使用的项目，进入工作区或对其进行项目配置，也可以创建项目、一键导入CDN。
以组织管理员（主账号）身份登录DataWorks管理控制台页面。
如下图所示：注意：概览界面是根据您的使用情况和创建时间，仅显示三个项目。
一般显示您最近使用和最近的创建时间项目。
页面说明如下：项目：显示您最近打开的三个项目，您可单击对应项目后的项目配置或进入工作区对项目进行具体操作。
您也可进入项目列表下进行相关操作，详情请参见项目列表。
常用功能：您可在此创建项目。
您也可在此一键导入CDN。
注意：如果子账号登录时，没有创建相应的项目，会提示请联系管理员，开通项目权限。
子账号最多显示两个项目，您可以进入项目列表页面查看全部项目。
如果子账号是部署的权限，则不能进入工作区。
阿里云数加平台管理控制台中，您可通过项目列表页面找到该账号下所有项目，可以对项目进行修改服务、进入工作区、配置项目、删除/激活和重试等操作，也可在此创建项目和刷新列表。
操作步骤以组织管理员（主账号）身份登录 DataWorks（数据工场，原大数据开发套件）产品详情页。
单击管理控制台，进入控制台概览页面。
导航至项目列表页面，该页面将显示此账号下的全部项目。
如下图所示：功能说明项目状态：项目一般分为正常、初始化中、初始化失败、删除中、删除五种状态。
创建项目开始会进入初始化中，后一般会显示两种结果初始化失败或正常。
项目创建成功后，您可以执行禁用和删除操作。
项目禁用后，您也可以激活和删除项目，激活后项目正常。
开通服务：您的鼠标移到服务上，会将您开通的服务全部展现出来，一般正常服务的图标会显示蓝色、欠费服务图标显示为红色并有相应的欠费标志、欠费已删除的服务是显示为灰色，一般服务欠费7天之后会自动删除。
项目配置您可通过配置项目操作，对当前项目一些基本属性和高级属性进行设置，主要对空间、调度等进行管理和配置。
数据库标准化与规范操作手册
数据库标准化与规范操作手册数据库的标准化与规范是保证数据一致性、完整性和可靠性的重要手段。
通过制定统一的标准和操作规范，可以提高数据库管理的效率和可维护性，并降低出错的概率。
本文将介绍数据库标准化与规范的基本原则和一些常用的操作手册。
一、数据库标准化原则1. 第一范式（1NF）：每个属性都是不可再分的，即确保数据的原子性。
确保每一列的值都是离散的，并且在每一个数据库中，每一个列都只包含一个数据元素。
这可以消除重复的数据，提高数据存储的效率。
例如，将含有重复信息的员工表拆分成员工信息表、部门信息表和工资信息表。
2. 第二范式（2NF）：表中的非主键属性完全依赖于主键，即确保数据的同质性。
非主键属性应当直接依赖于主键，而不是依赖于其他非主键属性，避免数据冗余和更新异常。
例如，将一个订单表拆分成客户信息表和订单信息表，以确保每个表只包含相关的信息。
3. 第三范式（3NF）：消除传递依赖，即确保数据的完整性。
每一个非主键属性都不能传递依赖于主键的其他非主键属性。
如有传递依赖情况，应将其拆分成多个表。
例如，将含有冗余信息的供应商表拆分成供应商信息表和产品信息表，保证表之间的关系更加清晰明确。
二、数据库规范操作1. 命名规范为了保证数据库的清晰易读和易维护，在命名对象时应遵循以下规范：- 表名：使用小写字母和下划线组合，具有具体和明确的含义。
- 字段名：遵循驼峰准则，使用具有具体和明确含义的字段名。
- 约束名：约束名的名称应当清晰明确，以便于理解和修改。
- 索引名：索引名的命名应当清晰明确，反映索引的用途和字段。
2. 数据库设计规范- 数据库表的字段应当根据其含义进行命名，清晰易懂。
- 字段的数据类型应当选择最适合其存储的数据类型。
- 为每个表设置一个主键，以确保数据表的唯一性和完整性。
- 适当地使用外键来定义表之间的关系，以确保数据的一致性。
- 设计合适的索引，以提高数据查询的速度。
3. 数据库操作规范- 对于表的操作，应在事务的保护下进行，以保护数据的完整性和一致性。
阿里巴巴平台操作指南PPT课件
如果同为橱窗产品，先排谁呢？
主要和四个因素有关：信息匹配度、信息完整性、信息专业度、买家喜好度
信息匹配度：按照产品的标题、关键词、简要描述、详细描述等因素进行匹配；匹配 精度越高，排名越靠前； 信息完整性：产品各类专业属性信息填写的完整性、正确性； 信息专业度：客户填写的信息是否是符合买家采购习惯，是否符合行业规范，如一个 产品填写很多不相关的关键字会被买家认为不够专业； 买家喜好度：买家喜欢的产品，曝光率、反馈率高的产品，越有机会排名靠前，这些 和企业的知名度、图片质量、产品价格、买家来源等等都有关系。
4488
供应商建站能力
产品信息质量——产品名称
明确具体，适当添加修饰语
慎用特殊符号
切勿堆砌品名
符合买家拼写习惯
修饰语+关键词
4499
产品信息质量——产品名称
搜索重点在标题
什么是用最少的产品覆盖最多的关键词?? 简单的说，标题中可组合的关键组数越多越好
1. 产品标题: A+B+C+D+E+F +G K1: D+E+F+G K2: E+F+G K3: F+G
8844
提醒：
1. 有业务员离职时需做好帐号管理和业务交接； 2. 交易中提高警惕，做好合同或协议的签订，保存好交易证据，保
护好自身利益 ; 3. 诚信经营 。
8855
每天开门6件事
1、TM自动登录 2、检查橱窗主关键词排名位置（争取在前2页都能找到） 3、找出橱窗主关键词排名最不理想做优化 4、每天坚持发布10-20个产品 5、下班前记得更新橱窗1次（排名第一页的可以不用更新） 6、每周四记得查看数据管家一次，看曝光、点击比上周增
阿里dataworks操作手册
阿里dataworks操作手册一、概述阿里dataworks是阿里巴巴集团推出的一款数据开发与运维一体化的云端数据集成解决方案，为用户提供了完整的数据开发生命周期解决方案，包括数据准备、数据开发、数据质量管理、数据运维和数据安全等功能。
作为阿里巴巴集团内部使用的数据管理评台，dataworks 已经成熟、稳定，并且在多个业务场景中得到了验证。
二、功能概述1.数据准备1.1 数据源管理：支持多种数据源接入，包括关系型数据库、非关系型数据库、Hadoop、文件等，用户可以自主创建数据源连接。
1.2 数据抽取：支持各类数据的抽取和数据同步，包括全量抽取、增量抽取、实时同步等。
1.3 数据准备：支持数据清洗、数据整理、数据归档等数据准备工作。
2.数据开发2.1 数据建模：支持数据模型的设计和管理，包括逻辑数据模型、物理数据模型等。
2.2 数据开发：提供完善的数据开发工具，支持SQL编辑、数据建模、数据计算等功能。
2.3 数据调度：支持数据调度的配置和管理，用户可以设置数据作业的调度周期、依赖关系等。
3.数据质量管理3.1 数据质量监控：提供数据质量监控功能，用户可以实时监控数据质量的情况。
3.2 数据质量评估：支持对数据质量进行评估和分析，用户可以了解数据质量的整体情况。
4.数据运维4.1 运维监控：提供数据运维监控功能，用户可以实时监控数据作业的运行状态。
4.2 运维报警：支持对数据运维情况进行报警，用户可以设置报警规则和接收报警通知。
5.数据安全5.1 数据权限管理：支持数据权限的管理和控制，包括用户权限、角色权限等。
5.2 数据安全审计：提供数据安全审计功能，记录用户操作日志、数据访问日志等。
三、操作手册1.数据源管理1.1 新建数据源1.1.1 登入dataworks控制台，在左侧导航栏选择“数据源”。
1.1.2 点击“新建数据源”，选择数据源类型，填写相应的连接信息。
1.1.3 测试连接，验证数据源连接是否成功。
阿里云分析型数据库-使用手册
第一章 快速开始
1.1 开通阿里云分析型数据库服务
在公共云上，满足开通条件的用户可以在 https:///ads 上进行按量付费开通，或访问 https:///?commodityCode=prepaid_ads#/buy 购买包月套餐。 在专有云中，开通分析型数据库服务的方式请咨询您的系统管理员或运维人员。
1.2 创建数据库
分析型数据库中，需要通过DMS for Analytic DB页面进行创建数据库。 在目前的分析型数据库版本中，创建数据库时，需要填写数据库名，注意这个数据库名称需要在分析型数据库 全部集群上全局唯一。然后选择分析型数据库的Region所在地，如杭州、北京等。 分析型数据库以ECU（弹性计算单元）作为资源计量的最小单位。ECU（弹性计算单元）拥有多种型号，每种 型号的ECU，标识着不同的vCPU核数、内存大小、磁盘空间大小。用户在创建数据库时需要根据自己的需求选 择这个数据库的ECU型号，以及初始的ECU数量（必须是偶数个，至少两个），ECU型号DB创建后不可修改 ，ECU数量可以在使用中随时调整（扩容/缩容），关于ECU的详细信息，详见 2.4节 ECU详解。 填好所有选项后，点击创建数据库，若返回错误，则根据错误提示进行修正（通常是数据库名称重复或不符合 规范，或提交的ECU资源量超过了分析型数据库允许的最大限制），否则则创建成功。十分钟以内DMS界面中 会显示出新的数据库的连接地址。
1.4 导入数据
分析型数据库支持多种接入数据的方式，您可以直接将数据通过insert/delete SQL写入实时表（详见使用手册 第四章），或通过Kettle等ETL工具将本地文件写入分析型数据库，或是通过阿里云数据传输从阿里云RDS中实 时同步数据变更（见使用手册8.5节），或者建立批量导入表从阿里云MaxCompute（原名ODPS）大批量的导 入数据。 如果在建立表时选择数据来源是批量导入，则分析型数据库提供多种数据导入的方式，如通过data pipeline系 列命令（详见5.1），等方式。在这里，作为测试使用，我们通过控制台界面进行数据导入。 在操作导入数据之前，我们需要对数据的来源表进行授权，例如数据的来源表在odps上，在公有云上则需要在 ODPS上对 garuda_build@ 授予describe和select权限（各个专有云授权的账号名参照专有云的相 关配置文档，不一定是这个账号）。另外要注意，分析型数据库目前仅允许操作者导入自身为Project Owner的ODPS Project中，或者操作者是ODPS表的Table Creator的数据。 进入DMS页面，选择菜单栏上的导入按钮，弹出导入对话框。这里我们的数据源表在阿里云ODPS上。因此数 据导入路径按照 "odps://project_name/table_name/partition_spec" 的格式来填写。关于导入数据的分区信 息，在仅有Hash分区的情况下iDB Cloud会帮我们自动识别并填写。填写完毕后，如下图所示，点击"确定"按 钮。
阿里云操作手册
阿里云是阿里巴巴集团旗下的云计算服务提供商，提供包括计算、存储、数据库、网络、安全等多种云服务。
操作阿里云需要按照具体的服务和需求进行操作，以下是一般性的阿里云基本操作手册的大致内容：1. 注册和登录：-注册阿里云账号。
-登录阿里云控制台。
2. 云服务器（ECS）操作：-创建和配置云服务器实例。
-安全组设置和网络配置。
-远程连接和管理服务器。
3. 存储服务操作：-使用对象存储服务（OSS）上传和下载文件。
-使用块存储服务（EBS）管理云硬盘。
-配置文件存储服务（NAS）。
4. 数据库服务操作：-创建和管理云数据库（RDS）。
-使用NoSQL数据库服务（Table Store）。
-设置和管理缓存服务（Redis）。
5. 网络服务操作：-配置和管理云网络（VPC）。
-设置弹性公网IP和负载均衡。
-配置安全组和访问控制。
6. 域名和网站操作：-注册和管理域名。
-配置CDN加速服务。
-部署和管理云主机上的网站。
7. 安全和监控：-设置访问控制和权限。
-使用安全服务（WAF、安骑士）。
-配置监控和警报。
8. 容器服务操作：-使用容器服务（Kubernetes）部署和管理容器应用。
-使用容器镜像服务（Container Registry）。
9. Serverless服务操作：-使用函数计算（Function Compute）。
-设置API网关和消息服务（MNS）。
10. 开发者工具：-使用阿里云命令行工具CLI。
-使用开发者工具（SDK）进行开发。
11. 财务管理：-查看和管理费用和账单。
-设置预算和报警。
12. 升级和扩展：-升级和扩展云资源。
-了解和使用阿里云市场的服务。
请注意，以上是一般性的操作手册大纲，具体的操作步骤和细节可能会因服务类型和版本的不同而有所变化。
建议查阅阿里云官方文档，以获取最准确和最新的操作指南。
阿里规范手册
阿里规范手册阿里规范手册是阿里巴巴集团内部制定的一套技术规范和最佳实践指南，旨在提高代码质量、降低维护成本、提高开发效率和协同开发能力。
该手册涵盖了多个领域，包括Java、前端、移动端、数据库、安全等，是阿里巴巴集团内部技术团队的必备参考资料。
阿里规范手册的主要特点是规范、实用、易读、易用。
它不仅包含了代码编写规范，还包括了代码质量检查工具、最佳实践指南、开发流程规范等内容，可以帮助开发者更好地理解和遵守规范，提高代码质量和开发效率。
在Java领域，阿里规范手册提出了一系列的编码规范和最佳实践，包括命名规范、代码风格、异常处理、日志记录、并发编程等方面。
这些规范和最佳实践都是基于阿里巴巴集团内部的实践经验和技术积累，具有很高的参考价值和实用性。
在前端领域，阿里规范手册提出了一系列的HTML、CSS、JavaScript 编码规范和最佳实践，包括代码结构、命名规范、代码风格、性能优化等方面。
这些规范和最佳实践可以帮助前端开发者更好地组织和管理代码，提高代码质量和性能。
在移动端领域，阿里规范手册提出了一系列的iOS、Android编码规范和最佳实践，包括代码结构、命名规范、代码风格、性能优化等方面。
这些规范和最佳实践可以帮助移动端开发者更好地组织和管理代码，提高代码质量和性能。
在数据库领域，阿里规范手册提出了一系列的SQL编码规范和最佳实践，包括表设计、索引设计、SQL语句编写等方面。
这些规范和最佳实践可以帮助数据库开发者更好地设计和管理数据库，提高数据库性能和可维护性。
在安全领域，阿里规范手册提出了一系列的安全编码规范和最佳实践，包括输入验证、输出编码、访问控制等方面。
这些规范和最佳实践可以帮助开发者更好地保护应用程序的安全性，防止各种安全漏洞和攻击。
总之，阿里规范手册是一份非常有价值的技术参考资料，可以帮助开发者更好地理解和遵守规范，提高代码质量和开发效率。
同时，阿里规范手册也是阿里巴巴集团内部技术团队的一份重要的技术文化，体现了阿里巴巴集团在技术领域的领先地位和创新精神。
Alibaba Cloud 云数据库 PolarDB API 参考说明书
云数据库 PolarDB API参考··法律声明法律声明阿里云提醒您在阅读或使用本文档之前仔细阅读、充分理解本法律声明各条款的内容。
如果您阅读或使用本文档，您的阅读或使用行为将被视为对本声明全部内容的认可。
1. 您应当通过阿里云网站或阿里云提供的其他授权通道下载、获取本文档，且仅能用于自身的合法合规的业务活动。
本文档的内容视为阿里云的保密信息，您应当严格遵守保密义务；未经阿里云事先书面同意，您不得向任何第三方披露本手册内容或提供给任何第三方使用。
2. 未经阿里云事先书面许可，任何单位、公司或个人不得擅自摘抄、翻译、复制本文档内容的部分或全部，不得以任何方式或途径进行传播和宣传。
3. 由于产品版本升级、调整或其他原因，本文档内容有可能变更。
阿里云保留在没有任何通知或者提示下对本文档的内容进行修改的权利，并在阿里云授权通道中不时发布更新后的用户文档。
您应当实时关注用户文档的版本变更并通过阿里云授权渠道下载、获取最新版的用户文档。
4. 本文档仅作为用户使用阿里云产品及服务的参考性指引，阿里云以产品及服务的“现状”、“有缺陷”和“当前功能”的状态提供本文档。
阿里云在现有技术的基础上尽最大努力提供相应的介绍及操作指引，但阿里云在此明确声明对本文档内容的准确性、完整性、适用性、可靠性等不作任何明示或暗示的保证。
任何单位、公司或个人因为下载、使用或信赖本文档而发生任何差错或经济损失的，阿里云不承担任何法律责任。
在任何情况下，阿里云均不对任何间接性、后果性、惩戒性、偶然性、特殊性或刑罚性的损害，包括用户使用或信赖本文档而遭受的利润损失，承担责任（即使阿里云已被告知该等损失的可能性）。
5. 阿里云网站上所有内容，包括但不限于著作、产品、图片、档案、资讯、资料、网站架构、网站画面的安排、网页设计，均由阿里云和/或其关联公司依法拥有其知识产权，包括但不限于商标权、专利权、著作权、商业秘密等。
非经阿里云和/或其关联公司书面同意，任何人不得擅自使用、修改、复制、公开传播、改变、散布、发行或公开发表阿里云网站、产品程序或内容。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
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) 用应用账户登录数据库，SHOW USER检查是否连接到正确的schema。
严禁使用sys、system等用户建表。
b) 执行建表脚本。
若一次建表个数超过三个以上，要求将脚本事先保存为文本文件，上传至数据库服务器，执行时使用@create_table_ddl.sql的方式直接执行。
c) 查看过程若无报错，退出当前登录。
若有报错，找出报错的地方，修改确认再执行，直至全部执行通过，最后退出当前登录。
3. 验证方案a) 常规检查：@dbcheckb) 检查表定义是否与测试库一致：exec pkg_pareObject(’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 || ‘ rows commit.’);–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) 执行订正脚本。
查看订正进度，使用如下脚本：select client_info from v$session where client_info is not null;–这个脚本必须配合前面描述的“进度报告”脚本执行。
c) 检查undo消耗: @undod) 检查表空间消耗: @tbse) 检查归档空间f) 检查同步延时是否异常。
g) 如果需要刷新应用缓存，在订正结束后通知应用刷新缓存。
3. 验证方案a) 以应用验证为主，数据库辅助做一些count等验证。
以应用验证通过为操作成功标准。
五、核心对象风险l 考虑到对erosa和otter的影响，严禁数据订正更新主键值。
六、回退方案按照备份时所做的各种不同的回退方案进行回退，回退之后也要要求应用做验证。
03-创建、删除、修改sequence一、目的明确定义对于sequence对象的操作风险及步骤。
二、适用范围l 项目发布创建新sequence。
l 以删除、重建的方式修改sequence的起始值。
l 在线修改sequence的cache值。
三、风险评估l Sequence命名与应用程序中不一致，导致应用无法正常访问sequence。
l 双向同步的库，多库创建同名sequence，起始值和步长值设置不合理，导致生成的值在表中对应主键值同步产生冲突。
l 删除、重建sequence的过程中，应用无法访问sequence，高并发的应用可能会产生故障。
l 删除、重建sequence之后没有对sequence的权限进行恢复，导致原本访问该sequence的其他schema无法正常访问。
l Sequence的cache设置不合理，设置过小会导致大量的系统相关等待，反之则导致sequence 生成值断层过多浪费严重。
l Java程序的int16数据类型只能容纳最大21亿，所以sequence不能超过这个值，如果有可能超过，需要跟开发确认。
四、操作流程1. 准备工作a) 默认使用变更系统生成的sequence名称，如果要修改，必须跟开发人员沟通一致。
b) 与开发人员、项目发布负责人沟通变更时间点。
对于删除、重建的操作必须明确告诉他们其间会有短暂的无法访问，如果是高并发的应用则选择在系统访问量最低的时候执行，规避风险。
c) 根据并发数确定cache值，默认为100，如遇特殊需求，酌情调整。
d) 删除、重建的操作，事先检查是否有其他schema拥有对于该sequence的访问权限：SELECT grantee, owner, table_name, privilegeFROM dba_tab_privsWHERE table_name = upper(’重建的对象名‘);e) 全面考虑同步的风险，确定同步环节中各个数据库的同名sequence起始值及步长，保证不会发生冲突，通常有如下两种做法：i. 起始值相差不大，步长值等于数据库个数。
以双库同步为例，起始值分别设为1和2，步长均设为2。
ii. 起始值相距较大，步长值相同。
以双库同步为例，A库起始值设为1，B库起始值设为2亿，步长均设为1。
相差的值可以根据增长预期进行调整。
2. 执行过程a) 标准新建脚本：CREATE SEQUENCE seq_tablename START WITH 1 CACHE 100;命名规范：seq_tablename默认不指定recycle和max value。
b) 标准重建脚本：DROP SEQUENCE seq_tablename ;CREATE SEQUENCE seq_tablename START WITH 1 CACHE 100;为了尽量缩短sequence不可用时间，这两个语句一起放在SecureCRT的chartWindow中一起执行。
c) 标准修改cache脚本：ALTER SEQUENCE seq_tablename CACHE 200;d) 标准赋权脚本：GRANT SELECT ON seq_tablename to username;3. 验证方案a) @dbcheck 检查是否有失效对象b) 通知应用验证是否可以正常访问sequence五、核心对象风险高并发对象重建时短暂不可访问；04_增加、删除唯一约束一、目的明确增删唯一约束操作的风险及标准流程，最大限度避免增删唯一约束操作带来的故障。