• 关于

    oracle 删除实例

    的搜索结果

回答

本文介绍如何使用数据传输服务DTS(Data Transmission Service),将自建Oracle数据迁移至RDS MySQL实例。DTS支持结构迁移、全量数据迁移以及增量数据迁移,同时使用这三种迁移类型可以实现在本地应用不停服的情况下,平滑地完成Oracle数据库的数据迁移。 源库支持的实例类型 进行数据迁移操作的Oracle数据库支持以下实例类型: 有公网IP的自建数据库 ECS上的自建数据库 通过专线/VPN网关/智能网关接入的自建数据库 本文以有公网IP的自建数据库为例介绍配置流程,其他实例类型的自建Oracle数据库配置流程与该案例类似。 前提条件 自建Oracle数据库的版本为9i、10g或11g版本。 自建Oracle数据库已开启Supplemental Logging,且要求supplemental_log_data_pk,supplemental_log_data_ui已开启,详情请参见Supplemental Logging。 自建Oracle数据库已开启ARCHIVELOG(归档模式),设置合理的归档日志保持周期且归档日志能够被访问,详情请参见ARCHIVELOG。 自建Oracle数据库的服务端口已开放至公网。 RDS MySQL实例的存储空间须大于自建Oracle数据库占用的存储空间。 注意事项 DTS在执行全量数据迁移时将占用源库和目标库一定的读写资源,可能会导致数据库的负载上升,在数据库性能较差、规格较低或业务量较大的情况下(例如源库有大量慢SQL、存在无主键表或目标库存在死锁等),可能会加重数据库压力,甚至导致数据库服务不可用。因此您需要在执行数据迁移前评估源库和目标库的性能,同时建议您在业务低峰期执行数据迁移(例如源库和目标库的CPU负载在30%以下)。 如果源数据库没有主键或唯一约束,且所有字段没有唯一性,可能会导致目标数据库中出现重复数据。 RDS MySQL实例对表名的英文大小写不敏感,如果使用大写英文建表,RDS MySQL会先把表名转为小写再执行建表操作。 如果源Oracle数据库中存在表名相同仅大小写不同的表,可能会导致迁移对象重名并在结构迁移中提示“对象已经存在”。如果出现这种情况,请在配置迁移对象的时候,使用DTS提供的对象名映射功能对重名的对象进行重命名,详情请参见库表列映射。 如果待迁移的数据库在目标RDS MySQL实例中不存在,DTS会自动创建。但是对于如下两种情况,您需要在配置迁移任务之前在目标RDS MySQL实例中创建数据库。 数据库名称不符合RDS定义规范,详细规范请参见创建数据库。 待迁移数据库在源Oracle数据库与目标RDS MySQL实例中的名称不同。 费用说明 迁移类型 链路配置费用 公网流量费用 结构迁移/全量数据迁移 不收费。 通过公网将数据迁移出阿里云时将收费,详情请参见产品定价。 增量数据迁移 收费,详情请参见产品定价。 迁移类型说明 结构迁移 DTS支持结构迁移的对象为表和索引,暂不支持视图、同义词、触发器、存储过程、存储函数、包、自定义类型等。表和索引的结构迁移存在以下限制: 表:不支持嵌套表;对于聚簇表和索引组织表,会在目标端转换成普通的表。 索引:不支持Function-Based Index、Domain Index、Bitmap Index和ReverseIndex。 全量数据迁移 DTS会将自建Oracle数据库迁移对象的存量数据,全部迁移到目标RDS MySQL实例数据库中 。 说明 为保障数据一致性,全量数据迁移期间请勿在自建Oracle数据库中写入新的数据。 增量数据迁移 在全量迁移的基础上,DTS会轮询并捕获自建Oracle数据库产生的redolog,将自建Oracle数据库的增量更新数据同步到目标RDS MySQL实例数据库中。通过增量数据迁移可以实现在本地应用不停服的情况下,平滑地完成Oracle数据库的数据迁移工作。 增量数据迁移支持同步的SQL操作 INSERT、DELETE、UPDATE CREATE TABLE 说明 表内定义不能包含函数。 ALTER TABLE、ADD COLUMN、DROP COLUMN、RENAME COLUMN、ADD INDEX DROP TABLE RENAME TABLE、TRUNCATE TABLE、CREATE INDEX 数据库账号权限要求 数据库 结构迁移 全量迁移 增量数据迁移 自建Oracle数据库 schema的owner权限 schema的owner权限 SYSDBA RDS MySQL实例 待迁入数据库的写权限 待迁入数据库的写权限 待迁入数据库的写权限 数据库账号创建及授权方法: 自建Oracle数据库请参见CREATE USER和GRANT。 RDS MySQL实例请参见创建账号和修改账号权限。 数据类型映射关系 详情请参见异构数据库间的数据类型映射关系。 操作步骤 登录数据传输控制台。 在左侧导航栏,单击数据迁移。 在迁移任务列表页面顶部,选择迁移的目标实例所属地域。选择地域 单击页面右上角的创建迁移任务。 配置迁移任务的源库及目标库信息。 源库和目标库连接配置 类别 配置 说明 任务名称 - DTS会自动生成一个任务名称,建议配置具有业务意义的名称(无唯一性要求),便于后续识别。 源库信息 实例类型 选择有公网IP的自建数据库。 实例地区 当实例类型选择为有公网IP的自建数据库时,实例地区无需设置。 说明 如果您的自建Oracle数据库进行了白名单安全设置,您需要在实例地区配置项后,单击获取DTS IP段来获取到DTS服务器的IP地址,并将获取到的IP地址加入自建Oracle数据库的白名单安全设置中。 数据库类型 选择Oracle。 主机名或IP地址 填入自建Oracle数据库的访问地址,本案例填入公网地址。 端口 填入自建Oracle数据库的服务端口,默认为1521。 实例类型 非RAC实例:选择该项后,您还需要填写SID信息。 RAC实例:选择该项后,您还需要填写ServiceName信息。 数据库账号 填入自建Oracle的数据库账号,权限要求请参见迁移账号权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 源库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的源库信息是否正确。源库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的源库信息。 目标库信息 实例类型 选择RDS实例。 实例地区 选择目标RDS实例所属地域。 RDS实例ID 选择目标RDS实例ID。 数据库账号 填入目标RDS实例的数据库账号,权限要求请参见迁移账号权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 目标库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的目标库信息是否正确。目标库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的目标库信息。 配置完成后,单击页面右下角的授权白名单并进入下一步。 说明 此步骤会将DTS服务器的IP地址自动添加到目标RDS实例的白名单中,用于保障DTS服务器能够正常连接目标RDS实例。 选择迁移对象及迁移类型。 选择迁移类型和迁移对象 配置 说明 迁移类型 如果只需要进行全量迁移,同时勾选结构迁移和全量数据迁移。 说明 为保障数据一致性,全量数据迁移期间请勿在自建Oracle数据库中写入新的数据。 如果需要进行不停机迁移,同时勾选结构迁移、全量数据迁移和增量数据迁移。 迁移对象 在迁移对象框中选中待迁移的对象,单击向右小箭头将其移动到已选择对象框。 说明 迁移对象选择的粒度可以为库、表、列三个粒度。 默认情况下,迁移完成后,迁移对象名跟自建Oracle数据库一致。如果您需要迁移对象在目标RDS实例上名称不同,那么需要使用DTS提供的对象名映射功能。使用方法请参见库表列映射。 单击页面右下角的预检查并启动。 说明 在迁移任务正式启动之前,会先进行预检查。只有预检查通过后,才能成功启动迁移任务。 如果预检查失败,单击具体检查项后的提示,查看失败详情。根据提示修复问题后,重新进行预检查。 预检查通过后,单击下一步。 在购买配置确认页面,选择链路规格并勾选数据传输(按量付费)服务条款。 单击购买并启动,迁移任务正式开始。 全量数据迁移 请勿手动结束迁移任务,否则可能导致数据不完整。您只需等待迁移任务完成即可,迁移任务会自动结束。 增量数据迁移 迁移任务不会自动结束,您需要手动结束迁移任务。 说明 请选择合适的时间手动结束迁移任务,例如业务低峰期或准备将业务切换至目标实例时。 观察迁移任务的进度变更为增量迁移,并显示为无延迟状态时,将源库停写几分钟,此时增量迁移的状态可能会显示延迟的时间。 等待迁移任务的增量迁移再次进入无延迟状态后,手动结束迁移任务。无延迟 将业务切换至RDS实例。 后续操作 用于数据迁移的数据库帐号拥有读写权限,为保障数据库安全性,请在数据迁移完成后,删除自建Oracle数据库和RDS MySQL实例中的数据库帐号。 更多信息 DTS支持在自建Oracle数据迁移至RDS MySQL实例时的数据反向回流,您可以使用该功能将RDS MySQL实例中产生的数据变化同步回自建Oracle数据库。如您有相关需求,请提交工单申请开通。

游客yl2rjx5yxwcam 2020-03-08 14:04:46 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档DTS在启动迁移之前,会进行前置预检查,本小节简单介绍Oracle->RDS For PPAS的预检查内容: 预检查项 检查内容 备注 源库连接性检查 检查DTS服务同Oracle实例的连通性 (1) 填写信息是否有误?如果填写信息有误,请修改后重新预检查(2) 检查Oracle是否开启监听端口 目的库连接性检查 检查DTS服务同目的RDS For PPAS实例的连通性 检查填写信息是否有误,如果有误请先修改后重新预检查 源库版本检查 检查Oracle实例的版本,DTS是否支持 DTS目前只支持10g,11g,12c三个版本 源库权限检查 检查Oracle实例访问账号的权限是否满足要求 如果权限不足,请参照上面的权限要求一节授权后,重新预检查 目的库权限检查 检查RDS For PPAS实例访问账号的权限是否满足要求 如果权限不足,请参照上面的权限要求一节授权后,重新预检查 同名对象存在性检查 检查待迁移对象在目标RDS For PPAS是否已经存在 如果检查失败,请将目标库中这些已经存在的对象删除后,重新进行预检查 源端同名对象存在性检查 检查待迁移对象中,要迁入目标同一个schema的对象是否同名 如果检查失败,可以参考 库表列映射 将重名对象进行重命名 源库日志模式检查 检查源库是否开启archive log 如果未开启,请启用后,重新预检查 约束完整性检查 检查待迁移对象依赖的父对象是否迁移 如果检查失败,那么可以修改迁移对象,同时迁移依赖的父对象后,重新预检查 DBLINK存在性检查 检查源库是否存在DBLINK 如果存在,那么需要修改迁移对象,不选择DBLINK 增量拓扑冲突检查 检查同一个迁移对象是否已经存在迁移链路 如果存在冲突链路,那么需要删除掉冲突链路后,重新预检查 字段类型检查 检查待迁移表的是否存在数据类型为long类型的字段 如果存在那么对应的表只能进行全量数据迁移,不能选择增量数据迁移 表是否存在主键或者唯一性非空索引检查 检查待迁移表是否包含主键或非空唯一键 如果存在那么对应的表只能进行全量数据迁移,不能选择增量数据迁移 补偿日志开启检查 检查是否开启supplemental_log 如果未开启,请启用后,重新预检查

2019-12-01 23:09:43 0 浏览量 回答数 0

问题

数据传输服务DTS的功能特性(什么是数据迁移?)

云栖大讲堂 2019-12-01 21:23:49 1218 浏览量 回答数 0

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

学生动手场景应用,快速了解并掌握云服务器的各种新奇玩法!

问题

OracleASM管理

男刊 2019-12-01 21:33:34 7934 浏览量 回答数 2

问题

使用 DTS 迁移 PPAS 数据

云栖大讲堂 2019-12-01 21:41:01 1084 浏览量 回答数 0

回答

本文简单介绍RDS MySQL及相关概念。 概述 阿里云关系型数据库(Relational Database Service,简称 RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储,RDS支持MySQL、SQL Server、PostgreSQL、PPAS(高度兼容 Oracle)和MariaDB引擎,并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。关于RDS的优势与价值,请参见产品优势。 如果您需要获取人工帮助,可以在RDS管理控制台的右上角选择工单 > 提交工单。如果业务复杂,您也可以购买支持计划,获取由IM企业群、技术服务经理(TAM)、服务经理等提供的专属支持。 有关阿里云关系型数据库RDS更多介绍信息,请查看产品详情 。 RDS MySQL RDS MySQL基于阿里巴巴的MySQL源码分支,经过双十一高并发、大数据量的考验,拥有优良的性能。RDS MySQL支持实例管理、账号管理、数据库管理、备份恢复、白名单、透明数据加密以及数据迁移等基本功能。除此之外还提供如下高级功能: 只读实例:在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法承受读取压力,甚至对业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,增加应用的吞吐量。 读写分离:读写分离功能是在只读实例的基础上,额外提供了一个读写分离地址,联动主实例及其所有只读实例,创建自动的读写分离链路。应用程序只需连接读写分离地址进行数据读取及写入操作,读写分离程序会自动将写入请求发往主实例,而将读取请求按照权重发往各个只读实例。用户只需通过添加只读实例的个数,即可不断扩展系统的处理能力,应用程序上无需做任何修改。 数据库独享代理:数据库独享代理服务是使用独立代理计算资源为当前实例提供代理服务,提供更多高级功能,例如读写分离、短连接优化、事务拆分等。 主机组:主机组功能是以集群形式批量管理实例,一个地域创建多个主机组,一个主机组包含多个主机,一个主机包含多个实例。 CloudDBA数据库性能优化:针对SQL语句性能、CPU使用率、IOPS使用率、内存使用率、磁盘空间使用率、连接数、锁信息、热点表等,CloudDBA提供了智能的诊断及优化功能,能最大限度发现数据库存在的或潜在的健康问题。CloudDBA的诊断基于单个实例,会提供问题详情及相应的解决方案,为您维护实例带来极大的便利。 RDS MySQL支持的功能请参见MySQL功能概览。 声明 本文档中描述的部分产品特性或者服务可能不在您的购买或使用范围之内,请以实际商业合同和条款为准。本文档内容仅作为指导使用,文档中的所有内容不构成任何明示或暗示的担保。 基本概念 实例:一个独立占用物理内存的数据库服务进程,用户可以设置不同的内存大小、磁盘空间和数据库类型。其中内存的规格会决定该实例的性能。实例创建后可以变更配置和删除实例。 数据库:在一个实例下创建的逻辑单元,一个实例可以创建多个数据库,数据库在实例内的命名唯一。 地域和可用区:地域是指物理的数据中心。可用区是指在同一地域内,电力和网络互相独立的物理区域。更多信息请参考阿里云全球基础设施。 通用描述约定 描述 说明 本地数据库 指代部署在本地机房或者非阿里云RDS上的数据库。 RDS XX(XX 为 MySQL、SQL Server、PostgreSQL、PPAS或MariaDB) 指代某一数据库类型的RDS,如RDS MySQL是指在RDS上开通的数据库引擎为MySQL的实例。

游客yl2rjx5yxwcam 2020-03-09 10:46:43 0 浏览量 回答数 0

回答

本文简单介绍RDS MySQL及相关概念。 概述 阿里云关系型数据库(Relational Database Service,简称 RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储,RDS支持MySQL、SQL Server、PostgreSQL、PPAS(高度兼容 Oracle)和MariaDB引擎,并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。关于RDS的优势与价值,请参见产品优势。 如果您需要获取人工帮助,可以在RDS管理控制台的右上角选择工单 > 提交工单。如果业务复杂,您也可以购买支持计划,获取由IM企业群、技术服务经理(TAM)、服务经理等提供的专属支持。 有关阿里云关系型数据库RDS更多介绍信息,请查看产品详情 。 RDS MySQL RDS MySQL基于阿里巴巴的MySQL源码分支,经过双十一高并发、大数据量的考验,拥有优良的性能。RDS MySQL支持实例管理、账号管理、数据库管理、备份恢复、白名单、透明数据加密以及数据迁移等基本功能。除此之外还提供如下高级功能: 只读实例:在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法承受读取压力,甚至对业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,增加应用的吞吐量。 读写分离:读写分离功能是在只读实例的基础上,额外提供了一个读写分离地址,联动主实例及其所有只读实例,创建自动的读写分离链路。应用程序只需连接读写分离地址进行数据读取及写入操作,读写分离程序会自动将写入请求发往主实例,而将读取请求按照权重发往各个只读实例。用户只需通过添加只读实例的个数,即可不断扩展系统的处理能力,应用程序上无需做任何修改。 数据库独享代理:数据库独享代理服务是使用独立代理计算资源为当前实例提供代理服务,提供更多高级功能,例如读写分离、短连接优化、事务拆分等。 主机组:主机组功能是以集群形式批量管理实例,一个地域创建多个主机组,一个主机组包含多个主机,一个主机包含多个实例。 CloudDBA数据库性能优化:针对SQL语句性能、CPU使用率、IOPS使用率、内存使用率、磁盘空间使用率、连接数、锁信息、热点表等,CloudDBA提供了智能的诊断及优化功能,能最大限度发现数据库存在的或潜在的健康问题。CloudDBA的诊断基于单个实例,会提供问题详情及相应的解决方案,为您维护实例带来极大的便利。 RDS MySQL支持的功能请参见MySQL功能概览。 声明 本文档中描述的部分产品特性或者服务可能不在您的购买或使用范围之内,请以实际商业合同和条款为准。本文档内容仅作为指导使用,文档中的所有内容不构成任何明示或暗示的担保。 基本概念 实例:一个独立占用物理内存的数据库服务进程,用户可以设置不同的内存大小、磁盘空间和数据库类型。其中内存的规格会决定该实例的性能。实例创建后可以变更配置和删除实例。 数据库:在一个实例下创建的逻辑单元,一个实例可以创建多个数据库,数据库在实例内的命名唯一。 地域和可用区:地域是指物理的数据中心。可用区是指在同一地域内,电力和网络互相独立的物理区域。更多信息请参考阿里云全球基础设施。 通用描述约定 描述 说明 本地数据库 指代部署在本地机房或者非阿里云RDS上的数据库。 RDS XX(XX 为 MySQL、SQL Server、PostgreSQL、PPAS或MariaDB) 指代某一数据库类型的RDS,如RDS MySQL是指在RDS上开通的数据库引擎为MySQL的实例。

游客yl2rjx5yxwcam 2020-03-09 10:46:39 0 浏览量 回答数 0

回答

目测是ORM的映射类型有误~~比如你DAO层的删除方法传入的参数类型有误???没看到你的DAO代码,所以难说,不过从报错信息看,十有八九是delete方法的参数有误!! 查之~~改之~~回复 @我的中国梦:那么你的DAO方法里头,是否真的是接受int参数进行delete呢??~~~~另外如果你是采用hibernate自动生成DAO,那么更应该确认一下DAO的情况~~比如“getHibernateTemplate().delete()参数是一个pojo的实例”我穿的参数都是int类型的啊!我就在servlet里面有了一次string类型的转换,转换成了Integer。show_sql,看看打印出的SQL语句呗.还是JDBC好.Hibernate:selectusers0_.idasid0_,users0_.usernameasusername0_,users0_.passwordaspassword0_fromUsersusers0_应该是没找到要 删除的实体我用的是oracle,在oracle中id为number类型,我做删除是通过id来删除的,我就只在servlet里面做了一下转换integer。 lz你是不是这样写的delete方法 session.delete(id) Sessionsession=null;Usersuser=(Users)session.get(Users.class,id);session.delete(user); 贴下你的代码啊 atorg.accp.ay213.dao.Impl.UserDaoImpl.deleteUser(UserDaoImpl.java:88)atorg.accp.ay213.services.Impl.UserservicesImpl.deleteUser(UserservicesImpl.java:33)atorg.accp.ay213.servlet.deleteUserInfo.doPost(deleteUserInfo.java:43)atorg.accp.ay213.servlet.deleteUserInfo.doGet(deleteUserInfo.java:35) 这是你报错的代码位置。北大青鸟的项目??? 用hibernate自己的删除应该传入的是实体类对象,不是主键ID,至少new一个对象set一下主键ID再调用delete方法。如果直接使用ID删除,就自己写删除的sql语句。对哦!谢谢。但是我改了Sessionsession=null; try{ Usersuser=(Users)session.get(Users.class,id); session.delete(user); 这也报错啊!

爱吃鱼的程序员 2020-06-23 11:57:58 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 使用数据传输服务 (DTS) 将本地数据库迁移到 RDS for SQL Server,可以实现应用不停服务的情况下,平滑完成数据库的迁移工作。 背景信息 DTS 支持 SQL Server 数据结构迁移和全量迁移。 结构迁移 DTS 会将本地数据库的结构定义迁移到目标实例。目前DTS支持结构迁移的对象有:表、视图、表触发器、同义词、SQL 存储过程、SQL 函数、自定义类型、plan guid、rule、default。 全量迁移 DTS 会将本地数据库迁移对象的数据全部迁移到目标实例。如果在迁移过程中有增量更新的话,这些增量不会被迁移到目标库。所以建议在业务无写入时,使用 DTS 进行全量数据迁移。 迁移限制 将本地数据库迁移到 RDS 上有以下限制: 迁移过程中,不支持 DDL 操作。 结构迁移不支持 assemblies、库级存储过程、service broker、全文索引、全文目录、分布式 schema、分布式函数、CLR 标量函数、CLR 标值函数、内部表、聚合函数和系统的迁移。 如果使用了对象名映射功能后,依赖这个对象的其他对象可能迁移失败。 前提条件 已完成 RDS 实例数据库的准备,可参见设置内外网地址 和 创建数据库和账号SQL Server 2008 R2版。 操作步骤 本例以有公网 IP 的本地数据库迁移到 RDS 上为例。 准备本地数据 在正式迁移之前,需要先在本地数据库和RDS实例中创建迁移账号,并在RDS实例中创建要迁移的数据库,并将要迁移的数据库的读写权限授权给迁移账号。不同的迁移类型需要不同的权限,如下表所示。 迁移类型 结构迁移 全量迁移 本地数据库 select select RDS 实例 读写权限 读写权限 在本地数据库中创建迁移账号。create login username with password='password', default_database=mydb; go create user username for login username with default_schema=dbo; go参数说明: username:要创建的账号 password:该账号的登录密码 mydb:默认连接的数据库 dbo:默认的数据表 例:要创建账号为 William,密码为 Changme123 的账号访问数据 mydb 的数据表 dbo,命令如下: create login William with password='Changme123', default_database=mydb; go create user William for login William with default_schema=dbo; go 在本地数据库中给迁移账号授权,本地数据库中迁移账号的权限要求请参见上表。GRANT privileges ON tablename TO username WITH GRANT OPTION;参数说明: privileges:该账号的操作权限,如 SELECT、INSERT、UPDATE 等。如果要授权该账号所有权限,则使用 ALL tablename:表名。如果要授权该账号所有的表权限,则使用通配符 * username:要授权的账号名 WITH GRANT OPTION:授权该账号能使用GRANT命令,该参数为可选 例:授权账号 William 对所有数据库和表的所有权限,命令如下: GRANT ALL ON* TO William; 正式迁移操作 在 RDS 管理控制台 上单击迁移数据库,进入DTS,如下图所示。 单击创建在线迁移任务,进入创建迁移任务页面,如下图所示。 输入任务名称、本地数据库信息和目标数据库信息,单击授权白名单并进入下一步,如下图所示。 任务名称:自定义任务名称,可以保持默认值 源库信息 实例类型:本地数据库的实例类型,可以选择 有公网 IP 的自建数据库、ECS 上的自建数据库、RDS 实例、云数据库 MongoDB。 数据库类型:本地数据库的类型,可以选择 Oracle、MySQL、SQLServer、PostgreSQL、MongoDB。 主机名或IP地址:本地数据库的公网地址。 端口:本地数据库的公网端口。 账号:本地数据库的迁移账号。 密码:本地数据库迁移账号对应的密码。 目标库信息 实例类型:默认为 RDS 实例。 RDS实例ID:目标 RDS 实例的 ID。单击下拉菜单将自动联想当前登录管理控制台的账号的 RDS 实例,点击选择所需要的实例。 数据库名称:要迁移到目标数据库的名称。 账号:目标 RDS 数据库的迁移账号。 密码:目标 RDS 数据库迁移账号对应的密码。 择迁移类型,并在迁移对象中选择要迁移的对象,单击>将要迁移的对象放入已选择中,单击预检查并启动,如下图所示。 说明 数据迁移只会将本地数据库的数据(结构)复制一份到目标数据库,并不会对本地数据库数据(结构)造成影响 数据迁移过程中,不支持DDL操作,如进行DDL操作可能导致迁移失败 DTS增量迁移的时间最长支持15天,如果超过15天不停止任务,系统资源可能被回收 如果要修改迁移对象在目标数据库上的名字,可以在已选择列表右侧单击编辑 ,修改已选择的对象名称,如上图中4所示。 说明 以下以预检查不通过为例进行描述,如果预检查通过,请直接参见步骤 8。 系统显示预检查结果,如下图所示。 单击检测结果为失败的检测项后的!,查看失败详细信息,根据失败详细信息完成错误排查。 错误排查完毕后,在迁移任务列表页面,选择当前迁移任务,单击启动,如下图所示。 系统预检查通过后,单击确定,自动进行迁移任务,如下图所示。 后续操作 为了保证本地数据库安全,请在数据迁移完成后,删除本地数据库和 RDS 实例中的迁移账号。

2019-12-01 22:57:13 0 浏览量 回答数 0

问题

DTS数据迁移能提供哪些失败在线修复功能

云栖大讲堂 2019-12-01 21:25:05 1162 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 使用数据传输服务(DTS)将本地数据库迁移到 RDS for MySQL,可以实现应用不停服务的情况下,平滑完成数据库的迁移工作。 背景信息 DTS 数据迁移支持 MySQL 的结构迁移、全量迁移和增量迁移。 结构迁移 DTS 会将本地数据库的结构定义迁移到目标实例。目前 DTS 支持结构迁移的对象有:表、视图、触发器、存储过程、存储函数。 全量迁移 DTS 会将本地数据库迁移对象的数据全部迁移到目标实例。如果用户还选择了增量迁移,那么全量迁移过程中,为了保证数据一致性,无主键的非事务表会被锁定,锁定期间这些表无法写入,锁定时长依赖于这些表的数据量大小,在这些无主键非事务表迁移完成后,锁才会释放。 增量迁移 增量迁移会将迁移过程进行数据变更同步到目标实例,如果迁移期间进行了 DDL 操作,那么这些结构变更不会迁移到目标实例。 迁移限制 将本地数据库迁移到 RDS 上有以下限制。 迁移过程中,不支持 DDL 操作 结构迁移不支持 event 的迁移 如果使用了对象名映射功能后,依赖这个对象的其他对象可能迁移失败 当选择增量迁移时,本地 MySQL 实例需要开启 binlog,且本地库的 binlog_format 要为 row。如果本地 MySQL 为5.6版本时,它的 binlog_row_image 还须设置为 full 前提条件 已完成 RDS 实例数据库的准备,可参见申请外网地址和 MySQL 5.7高可用版/5.5/5.6创建数据库和账号。 操作步骤 本例以有公网 IP 的本地数据库迁移到 RDS 上为例。 准备本地数据 在正式迁移之前,需要先在本地数据库和 RDS 实例中创建迁移账号,并在 RDS 实例中创建要迁移的数据库,并将要迁移的数据库的读写权限授权给迁移账号。不同的迁移类型需要不同的权限,如下表所示。 迁移类型 结构迁移 全量迁移 增量迁移 本地数据库 select select select replication slave replication client RDS 实例 读写权限 读写权限 读写权限 在本地数据库中创建迁移账号。CREATE USER 'username'@'host' IDENTIFIED BY 'password';参数说明: username:要创建的账号 host:指定该账号登录数据库的主机。如果是本地用户可以使用 localhost,如果想让该用户从任意主机登录,可以使用通配符 % password:该账号的登录密码 例:要创建账号为 William,密码为 Changme123 的账号从任意主机登录本地数据库,命令如下: CREATE USER 'William'@'%' IDENTIFIED BY 'Changme123'; 在本地数据库中给迁移账号授权,本地数据库中迁移账号的权限要求请参见上表。GRANT privileges ON databasename.tablename TO 'username'@'host' WITH GRANT OPTION;参数说明: privileges:该账号的操作权限,如 SELECT、INSERT、UPDATE 等。如果要授权该账号所有权限,则使用 ALL databasename:数据库名。如果要授权该账号所有的数据库权限,则使用通配符 * tablename:表名。如果要授权该账号所有的表权限,则使用通配符 * username:要授权的账号名 host:授权登录数据库的主机名。如果是本地用户可以使用 localhost,如果想让该用户从任意主机登录,可以使用通配符 % WITH GRANT OPTION:授权该账号能使用GRANT命令,该参数为可选 例:授权账号 William 对所有数据库和表的所有权限,并可以从任意主机登录本地数据库,命令如下: GRANT ALL ON *.* TO 'William'@'%'; 说明 如果需要进行增量迁移,那么需要确认本地数据库的 binlog 是否开启并正确设置,执行以下步骤。 开启本地数据库的 binlog。 使用如下命令查询是否开启了binlog。show global variables like "log_bin";如果查询结果为 log_bin=OFF,那么本地数据库没有开启 binlog。为了使迁移过程中产生的增量数据能同步迁移,需要修改配置文件 my.cnf 中的如下参数。 log_bin=mysql_bin binlog_format=row server_id=大于 1 的整数 binlog_row_image=full //当本地 MySQL 版本大于 5.6 时,则需设置该项 修改完成后,重启 MySQL 进程。$mysql_dir/bin/mysqladmin -u root -p shutdown $mysql_dir/bin/safe_mysqld &其中,“mysql_dir”为MySQL安装目录。 正式迁移操作 数据准备完毕后,即可进入正式的迁移操作。 在 RDS 管理控制台 上单击迁移数据库,进入 DTS,如下图所示。 单击 创建在线迁移任务,进入 创建迁移任务 页面,如下图所示。 输入任务名称、本地数据库信息和目标数据库信息,单击 授权白名单并进入下一步,如下图所示。 任务名称:自定义任务名称,可以保持默认值 源库信息 实例类型:本地数据库的实例类型,可以选择有公网IP的自建数据库、ECS上的自建数据库、RDS实例、云数据库MongoDB 数据库类型:本地数据库的类型,可以选择 Oracle、MySQL、SQLServer、PostgreSQL、MongoDB 主机名或 IP 地址:本地数据库的公网地址 端口:本地数据库的公网端口 账号:本地数据库的迁移账号 密码:本地数据库迁移账号对应的密码 目标库信息 实例类型:默认为 RDS 实例 RDS 实例 ID:目标 RDS 实例的 ID。点击下拉菜单将自动联想当前登录 RDS 管理控制台 的账号的 RDS 实例,点击选择所需要的实例 账号:目标 RDS 数据库的迁移账号 密码:目标 RDS 数据库迁移账号对应的密码 择迁移类型,并在 迁移对象 中选择要迁移的对象,单击 > 将要迁移的对象放入已选择中,单击 预检查并启动,如下图所示。 说明 数据迁移只会将本地数据库的数据(结构)复制一份到目标数据库,并不会对本地数据库数据(结构)造成影响。 如果要修改迁移对象在目标数据库上的名字,可以在 已选择 列表右侧单击 编辑,修改已选择的对象名称,如上图4所示。 说明 以下以预检查不通过为例进行描述,如果预检查通过,请直接参见步骤 8。 系统显示预检查结果,如下图所示。 单击检测结果 为失败的检测项后的 !,查看失败详细信息,根据失败详细信息完成错误排查。 错误排查完毕后,在 迁移任务列表页面,选择当前迁移任务,单击 启动,如下图所示。 系统预检查通过后,单击确定,自动进行迁移任务,如下图所示。 后续操作 因迁移账号拥有读写权限,为了保证本地数据库安全,请在数据迁移完成后,删除本地数据库和 RDS 实例中的迁移账号。

2019-12-01 22:57:10 0 浏览量 回答数 0

问题

快速入门PPAS版-常用管理函数

李沃晟 2019-12-01 21:38:18 602 浏览量 回答数 0

问题

使用 DTS 迁移 SQL Server 数据

云栖大讲堂 2019-12-01 21:41:01 821 浏览量 回答数 0

问题

使用 DTS 迁移 MySQL 数据

云栖大讲堂 2019-12-01 21:40:55 1317 浏览量 回答数 0

问题

MaxCompute用户指南:安全指南:用户及授权管理:授权

行者武松 2019-12-01 22:05:45 1372 浏览量 回答数 0

问题

OSS存储服务客户端工具更新至v1.6版本

莫名 2019-12-01 21:18:07 39898 浏览量 回答数 16

问题

PHP实现DataGrid,报错?

一枚小鲜肉帅哥 2020-06-20 19:39:04 0 浏览量 回答数 1

回答

回2楼啊里新人的帖子 在日常的业务开发中,常见使用到索引的地方大概有两类: 第一类.做业务约束需求,比如需要保证表中每行的单个字段或者某几个组合字段是唯一的,则可以在表中创建唯一索引; 比如:需要保证test表中插入user_id字段的值不能出现重复,则在设计表的时候,就可以在表中user_id字段上创建一个唯一索引: CREATE TABLE `test` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `user_id` int(11) NOT NULL,   `gmt_create` datetime DEFAULT NULL,   PRIMARY KEY (`id`),   UNIQUE KEY `uk_userid` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ; 第二类.提高SQL语句执行速度,可以根据SQL语句的查询条件在表中创建合适的索引,以此来提升SQL语句的执行速度; 此过程好比是去图书找一本书,最慢的方法就是从图书馆的每一层楼每一个书架一本本的找过去;快捷一点的方法就是先通过图书检索来确认这一本书在几楼那个书架上,然后直接去找就可以了;当然创建这个索引也需要有一定的代价,需要存储空间来存放,需要在数据行插入,更新,删除的时候维护索引: 例如: CREATE TABLE `test_record` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `user_id` int(11) NOT NULL,   `gmt_create` datetime DEFAULT NULL,   PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=5635996 DEFAULT CHARSET=utf8 该表有500w的记录,我需要查询20:00后插入的记录有多少条记录: mysql> select count(*) from test_record where gmt_create>'2014-12-17 20:00:00'; +----------+ | count(*) | +----------+ |        1 | +----------+ 1 row in set (1.31 sec) 可以看到查询耗费了1.31秒返回了1行记录,如果我们在gmt_create字段上添加索引: mysql> alter table test_record add index ind_gmt_create(gmt_create); Query OK, 0 rows affected (21.87 sec) Records: 0  Duplicates: 0  Warnings: 0 mysql> select count(*) from test_record where gmt_create>'2014-12-17 20:00:00'; +----------+ | count(*) | +----------+ |        1 | +----------+ 1 row in set (0.01 sec) 查询只消耗了0.01秒中就返回了记录. 总的来说,为SQL语句(select,update,delete)创建必要的索引是必须的,这样虽然有一定的性能和空间消耗,但是是值得,尤其是在大并发的请求下,大量的数据被扫描造成系统IO和CPU资源消耗完,进而导致整个数据库不可服务. ------------------------- 怎么学好数据库是一个比较大题目,数据库不仅仅是写SQL那么简单,即使知道了SQL怎么写,还需要很清楚的知道这条SQL他大概扫描了多少数据,返回多少数据,是否需要创建索引。至于SQL优化是一个比较专业的技术活,但是可以通过学习是可以掌握的,你可以把一条sql从执行不出来优化到瞬间完成执行,这个过程的成就感是信心满满的。学习的方法可以有以下一些过程:1、自己查资料,包括书本,在线文档,google,别人的总结等等,试图自己解决2、多做实验,证明自己的想法以及判断3、如果实在不行,再去论坛问,或者问朋友4、如果问题解决了,把该问题的整个解决方法记录下来,以备后来的需要5、多关注别人的问题,或许以后自己就遇到了,并总是试图去多帮助别人6、习惯从多个方面去考虑问题,并且养成良好的总结习惯 下面是一些国内顶级数据库专家学习数据库的经验分享给大家: http://www.eygle.com/archives/2005/08/ecinieoracleouo.html 其实学习任何东西都是一样,没有太多的捷径可走,必须打好了坚实的基础,才有可以在进一步学习中得到快速提高。王国维在他的《人间词话》中曾经概括了为学的三种境界,我在这里套用一下: 古今之成大事业、大学问者,罔不经过三种之境界。"昨夜西风凋碧树。独上高楼,望尽天涯路。"此第一境界也。"衣带渐宽终不悔,为伊消得人憔悴。"此第二境界也。"众里寻他千百度,蓦然回首,那人却在灯火阑珊处。"此第三境界也。 学习Oracle,这也是你必须经历的三种境界。 第一层境界是说,学习的路是漫漫的,你必须做好充分的思想准备,如果半途而废还不如不要开始。 这里,注意一个"尽"字,在开始学习的过程中,你必须充分阅读Oracle的基础文档,概念手册、管理手册、备份恢复手册等(这些你都可以在http://tahiti.oracle.com 上找到);OCP认证的教材也值得仔细阅读。打好基础之后你才具备了进一步提升的能力,万丈高楼都是由地而起。 第二层境界是说,尽管经历挫折、打击、灰心、沮丧,也都要坚持不放弃,具备了基础知识之后,你可以对自己感兴趣或者工作中遇到的问题进行深入的思考,由浅入深从来都不是轻而易举的,甚至很多时候你会感到自己停滞不前了,但是不要动摇,学习及理解上的突破也需要时间。 第三次境界是说,经历了那么多努力以后,你会发现,那苦苦思考的问题,那百思不得其解的算法原理,原来答案就在手边,你的思路豁然开朗,宛如拨云见月。这个时候,学习对你来说,不再是个难题,也许是种享受,也许成为艺术。 所以如果你想问我如何速成,那我是没有答案的。 不经一番寒彻骨,哪得梅花扑鼻香。 当然这三种境界在实际中也许是交叉的,在不断的学习中,不断有蓦然回首的收获。 我自己在学习的过程中,经常是采用"由点及面法"。 当遇到一个问题后,一定是深入下去,穷究根本,这样你会发现,一个简单的问题也必定会带起一大片的知识点,如果你能对很多问题进行深入思考和研究,那么在深处,你会发现,这些面逐渐接合,慢慢的延伸到oracle的所有层面,逐渐的你就能融会贯通。这时候,你会主动的去尝试全面学习Oracle,扫除你的知识盲点,学习已经成为一种需要。 由实践触发的学习才最有针对性,才更能让你深入的理解书本上的知识,正所谓:" 纸上得来终觉浅,绝知此事要躬行"。实践的经验于我们是至为宝贵的。 如果说有,那么这,就是我的捷径。 想想自己,经常是"每有所获,便欣然忘食", 兴趣才是我们最好的老师。 Oracle的优化是一门学问,也是一门艺术,理解透彻了,你会知道,优化不过是在各种条件之下做出的均衡与折中。 内存、外存;CPU、IO...对这一切你都需要有充分的认识和相当的了解,管理数据库所需要的知识并不单纯。 作为一个数据库管理人员,你需要做的就是能够根据自己的知识以及经验在各种复杂情况下做出快速正确的判断。当问题出现时,你需要知道使用怎样的手段发现问题的根本;找到问题之后,你需要运用你的知识找到解决问题的方法。 这当然并不容易,举重若轻还是举轻若重,取决于你具备怎样的基础以及经验积累。 在网络上,Howard J. Rogers最近创造了一个新词组:Voodoo Tuning,用以形容那些没有及时更新自己的知识技能的所谓的Oracle技术专家。由于知识的陈旧或者理解的肤浅,他们提供的很多调整建议是错误的、容易使人误解的,甚至是荒诞的。他们提供的某些建议在有些情况下也许是正确的,如果你愿意回到Oracle5版或者6版的年代;但是这些建议在Oracle7.0,8.0 或者 Oracle8i以后往往是完全错误的。 后来基于类似问题触发了互联网内Oracle顶级高手的一系列深入讨论,TOM、Jonathan Lewis、HJR等人都参与其中,在我的网站上(www.eygle.com )上对这些内容及相关链接作了简要介绍,有兴趣的可以参考。 HJR给我们提了很好的一个提示:对你所需要调整的内容,你必须具有充分的认识,否则你做出的判断就有可能是错误的。 这也是我想给自己和大家的一个建议: 学习和研究Oracle,严谨和认真必不可少。 当然 你还需要勤奋,我所熟悉的在Oracle领域有所成就的技术人员,他们共同的特点就是勤奋。 如果你觉得掌握的东西没有别人多,那么也许就是因为,你不如别人勤奋。 要是你觉得这一切过于复杂了,那我还有一句简单的话送给大家: 不积跬步,无以至千里。学习正是在逐渐积累过程中的提高。 现在Itpub给我们提供了很好的交流场所,很多问题都可以在这里找到答案,互相讨论,互相学习。这是我们的幸运,我也因此非常感谢这个网络时代。 参考书籍: 如果是一个新人可以先买一些基本的入门书籍,比如MySQL:《 深入浅出MySQL——数据库开发、优化与管理维护 》,在进阶一点的就是《 高性能MySQL(第3版) 》 oracle的参考书籍: http://www.eygle.com/archives/2006/08/oracle_fundbook_recommand.html 最后建议不要在数据库中使用外键,让应用程序来保证。 ------------------------- Re:回 9楼(千鸟) 的帖子 我有一个问题想问问,现在在做一个与图书有关的项目,其中有一个功能是按图书书名搜索相似图书列表,问题不难,但是想优化一下,有如下问题想请教一下: 1、在图书数据库数据表的书名字段里,按图书书名进行关键字搜索,如何快速搜索相关的图书?   现在由于数据不多,直接用的like模糊查找验证功能而已; 如果数据量不大,是可以在数据库中完成搜索的,可以在搜索字段上创建索引,然后进行搜索查询: CREATE TABLE `book` (   `book_id` int(11) NOT NULL AUTO_INCREMENT,   `book_name` varchar(100) NOT NULL,   .............................   PRIMARY KEY (`book_id`),   KEY `ind_name` (`book_name`) ) ENGINE=InnoDB select book.*  from book , (select book_id from book where book_name like '%算法%')  book_search_id  where book.book_id=book_search_id.book_id; 但是当数据量变得很大后,就不在适合了,可以采用一些其他的第三方搜索技术比如sphinx; 2、如何按匹配的关键度进行快速排序?比如搜索“算法”,有一本书是《算法》,另一本书是《算法设计》,要求前者排在更前面。 现在的排序是根据数据表中的主键序号id进行的排序,没有达到想要的效果。 root@127.0.0.1 : test 15:57:12> select book_id,book_name from book_search where book_name like '%算%' order by book_name; +---------+--------------+ | book_id | book_name    | +---------+--------------+ |       2 | 算法       | |       1 | 算法设计 | ------------------------- 回 10楼(大黑豆) 的帖子 模糊查询分为半模糊和全模糊,也就是: select * from book where name like 'xxx%';(半模糊) select * from book where name like '%xxx%';(全模糊) 半模糊可以可以使用到索引,全模糊在上面场景是不能使用到索引的,但可以进行一些改进,比如: select book.*  from book , (select book_id from book where book_name like '%算法%')  book_search_id   where book.book_id=book_search_id.book_id; 注意这里book_id是主键,同时在book_name上创建了索引 上面的sql语句可以利用全索引扫描来完成优化,但是性能不会太好;特别在数据量大,请求频繁的业务场景下不要在数据库进行模糊查询; 非得使用数据库的话 ,建议不要在生产库进行查询,可以在只读节点进行查询,避免查询造成主业务数据库的资源消耗完,导致故障. 可以使用一些开源的搜索引擎技术,比如sphinx. ------------------------- 回 11楼(蓝色之鹰) 的帖子 我想问下,sql优化一般从那几个方面入手?多表之间的连接方式:Nested Loops,Hash Join 和 Sort Merge Join,是不是Hash Join最优连接? SQL优化需要了解优化器原理,索引的原理,表的存储结构,执行计划等,可以买一本书来系统的进行学习,多多实验; 不同的数据库优化器的模型不一样,比如oracle支持NL,HJ,SMJ,但是mysql只支持NL,不通的连接方式适用于不同的应用场景; NL:对于被连接的数据子集较小的情况,嵌套循环连接是个较好的选择 HJ:对于列连接是做大数据集连接时的常用方式 SMJ:通常情况下散列连接的效果都比排序合并连接要好,然而如果行源已经被排过序,在执行排序合并连接时不需要再排序了,这时排序合并连接的性能会优于散列连接 ------------------------- Re:回 19楼(原远) 的帖子 有个问题:分类表TQueCategory,问题表TQuestion(T-SQL) CREATE TABLE TQueCategory ( ID INT IDENTITY(1,1) PRIMARY KEY,        --问题分类ID NAME VARCHAR(20)        --问题分类名称 ) CREATE TABLE TQuestion ( ID INT IDENTITY(1,1) PRIMARY KEY,        --问题ID CateID INT NOT NULL,        --问题分类ID TITLE VARCHAR(50),        --问题标题 CONTENT VARCHAR(500)        --问题内容 ) 当前要统计某个分类下的问题数,有两种方式: 1.每次统计,在TQuestion通过CateID进行分组统计 SELECT CateID,COUNT(1) AS QueNum FROM TQuestion GROUP BY CateID WHERE 1=1 2.在TQueCategory表增加字段QueNum,用于标识该分类下的问题数量 ALTER TABLE TQueCategory ADD QueNum INT SELECT CateID,QueNum FROM TQueCategory 问:在哪种业务应用场景下采用上面哪种方式性能比较好,为什么? ############################################################################################### 方案 一 需要对 TQuestion 的 CateID字段 进行分组 ,可以在 CateID上创建一个索引,这样就可以索引扫描来完成查询; 方案 二 需要对 TQueCategory 进行扫描就可以得出结果,但是必须在问题表有插入,删除的时候维护quenum数量; 单单从SQL的性能来看, 分类表的数量应该是远远小于问题表的数量的,所以方案二的性能会比较好; 但是如果 TQuestion 的插入非常频繁的话,会带来对 TQueCategory的频繁更新,一次 TQuestion 的 insert或deleted就会带来一次 TQueCategory 的update,这个代价其实是蛮高的; 如果这个分类统计的查询不是非常频繁的话,建议还是使用方案一; 同时还可能还会其他的业务逻辑统计需求(例如: CateID +时间),这个时候在把逻辑放到 TQueCategory就不合适了。 ------------------------- 回 20楼(原远) 的帖子 经验之谈,仅供参考 使用外键在开发上确实省去了很多功夫,但是把业务逻辑交由数据库来完成,对后期的维护来说是很麻烦的事情,不利于维护. ------------------------- 回 21楼(玩站网) 的帖子 无关技术方面: 咨询一下,现在mysql新的版本,5.5.45后貌似修改了开源协议。 是否意味着今后我们商业化使用mysql将受到限制? 如果甲骨文真周到那一步,rds是否会受到影响? 一个疑惑: 为什么很少见到有人用mysql正则匹配?性能不好还是什么原因? ######################################## MySQL有商业版 和 社区版,RDS的MySQL采用开源的社区版进行改进,由专门的RDS MySQL源码团队来维护,国内TOP 10的mysql源码贡献者大部分都在RDS,包括了@丁奇 ,@彭立勋 ,@印风 等; 不在数据库中做业务计算,是保证数据库运行稳定的一个好的设计经验; 是否影响性能与你的sql的执行频率,需要参与的计算数据量相关,当然了还包括数据库所在主机的IO,cpu,内存等资源,离开了这些谈性能是没有多大意义的; ------------------------- 回 22楼(比哥) 的帖子 分页该怎么优化才行??? ######################### 可以参考这个链接,里面有很多的最佳实践,其中就包括了分页语句的优化: http://bbs.aliyun.com/read/168647.html?spm=5176.7114037.1996646101.1.celwA1&pos=1 普通写法: select  *  from t where sellerid=100 limit 100000,20 普通limit M,N的翻页写法,往往在越往后翻页的过程中速度越慢,原因 mysql会读取表中的前M+N条数据,M越大,性能就越差: 优化写法: select t1.* from  t t1,             (select id from t  sellerid=100 limit 100000,20) t2 where t1.id=t2.id; 优化后的翻页写法,先查询翻页中需要的N条数据的主键id,在根据主键id 回表查询所需要的N条数据,此过程中查询N条数据的主键ID在索引中完成 注意:需要在t表的sellerid字段上创建索引 create index ind_sellerid on t(sellerid); 案例: user_A (21:42:31): 这个sql该怎么优化,执行非常的慢: | Query   |   51 | Sending data | select id, ... from t_buyer where sellerId = 765922982 and gmt_modified >= '1970-01-01 08:00:00' and gmt_modified <= '2013-06-05 17:11:31' limit 255000, 5000 SQL改写:selectt2.* from (selectid from t_buyer where sellerId = 765922982   andgmt_modified >= '1970-01-01 08:00:00'   andgmt_modified <= '2013-06-05 17:11:31' limit255000, 5000)t1,t_buyer t2 where t1.id=t2.id index:seller_id,gmt_modified user_A(21:58:43): 好像很快啊。神奇,这个原理是啥啊。牛!!! user_A(21:59:55): 5000 rows in set (4.25 sec), 前面要90秒。 ------------------------- 回 27楼(板砖大叔) 的帖子 这里所说的索引都是普通的b-tree索引,mysql,sqlserver,oracle 的关系数据库都是默认支持的; ------------------------- 回 32楼(veeeye) 的帖子 可以详细说明一下“最后建议不要在数据库中使用外键,让应用程序来保证。 ”的原因吗?我们公司在项目中经常使用外键,用程序来保证不是相对而言更加复杂了吗? 这里的不建议使用外键,主要考虑到 : 第一.维护成本上,把一些业务逻辑交由数据库来保证,当业务需求发生改动的时候,需要同时考虑应用程序和数据库,有时候一些数据库变更或者bug,可能会导致外键的失效;同时也给数据库的管理人员带来维护的麻烦,不便于管理。 第二.性能上考虑,当大量数据写入的时候,外键肯定会带来一定的性能损耗,当出现这样的问题时候,再来改造去除外键,真的就不值得了; 最后,不在数据库中参与业务的计算(存储过程,函数,触发器,外键),是保证数据库运行稳定的一个好的最佳实践。 ------------------------- 回 33楼(优雅的固执) 的帖子 ReDBA专家门诊一期:索引与sql优化 十分想请大师分享下建立索引的经验 我平时简历索引是这样的 比如订单信息的话 建立 订单号  唯一聚集索引 其他的比如   客户编号 供应商编号 商品编号 这些建立非聚集不唯一索引   ################################################## 建立索引,需要根据你的SQL语句来进行创建,不是每一个字段都需要进行创建,也不是一个索引都不创建,,可以把你的SQL语句,应用场景发出来看看。 索引的创建确实是一个非常专业的技术活,需要掌握:表的存储方式,索引的原理,数据库的优化器,统计信息,最后还需要能够读懂数据库的执行计划,以此来判断索引是否创建正确; 所以需要进行系统的学习才能掌握,附件是我在2011年的时候的一次公开课的ppt,希望对你有帮助,同时可以把你平时遇到的索引创建的疑惑发到论坛上来,大家可以一起交流。 ------------------------- 回 30楼(几几届) 的帖子 我也是这样,简单的会,仔细写也会写出来,但是就是不知道有没有更快或者更好的 #################################################### 多写写SQL,掌握SQL优化的方法,自然这些问题不在话下了。 ------------------------- 回 40楼(小林阿小林) 的帖子 mysql如何查询需要优化的语句,比如慢查询的步奏,如何找出需要通知程序员修改或者优化的sql语句 ############################################################ 可以将mysql的慢日志打开,就可以记录执行时间超过指定阀值的慢SQL到本地文件或者数据库的slow_log表中; 在RDS中默认是打开了慢日志功能的:long_query_time=1,表示会记录执行时间>=1秒的慢sql; 如何快速找到mysql瓶颈: 简单一点的方法,可以通过监控mysql所在主机的性能(CPU,IO,load等)以及mysql本身的一些状态值(connections,thread running,qps,命中率等); RDS提供了完善的数据库监控体系,包括了CPU,IOPS,Disk,Connections,QPS,可以重点关注cpu,IO,connections,disk 4个 指标; cpu,io,connections主要体现在了性能瓶颈,disk主要体现了空间瓶颈; 有时候一条慢sql语句的频繁调用,也可能导致整个实例的cpu,io,connections达到100%;也有可能一条排序的sql语句,消耗大量的临时空间,导致实例的空间消耗完。 ------------------------- 下面是分析一个cpu 100%的案例分析:该实例的cpu已经到达100% 查看当前数据库的活动会话信息:当前数据库有较多的活跃线程在数据库中执行查看当前数据库正在执行的sql: 可以看到这条sql执行的非常缓慢:[tr=rgb(100, 204, 255)]delete from task_process where task_id='1801099' 查看这个表的索引: CREATE TABLE `task_process` (  `id` int(11) NOT NULL AUTO_INCREMENT,    ................  `task_id` int(11) NOT NULL DEFAULT '0' COMMENT '??????id',   ................  PRIMARY KEY (`id`),  KEY `index_over_task` (`is_over`,`task_id`),  KEY `index_over` (`is_over`,`is_auto`) USING BTREE,  KEY `index_process_sn` (`process_sn`,`is_over`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=32129710; 可以看到这个表有3KW的数据,但是没有task_id字段开头的索引,导致该sql语句删除需要进行全表扫描: 在我们的诊断报告中已经将该sql语句捕获到,同时给你提出该怎样进行索引的添加。 广告:诊断报告将会在1月底发布到控制台,到时候用户可以直接查看诊断建议,来完成你的数据库优化。 ------------------------- 回 45楼(dentrite) 的帖子 datetime和int都是占用数据库4个字节,所以在空间上没有什么差别;但是为了可读性,建议还是使用datetime数据类型。 ------------------------- 回 48楼(yuantel) 的帖子 麻烦把ecs_brand和ecs_goods的表结构发出来一下看看 。 ------------------------- 回 51楼(小林阿小林) 的帖子 普通的 ECS服务器上目前还没有这样的慢SQL索引建议的工具。 不过后续有IDBCloud将会集成这样的sql诊断功能,使用他来管理ECS上的数据库就可以使用这样的功能了 。

玄惭 2019-12-02 01:16:11 0 浏览量 回答数 0

问题

干货分享:DBA专家门诊一期:索引与sql优化问题汇总

xiaofanqie 2019-12-01 21:24:21 74007 浏览量 回答数 38

回答

在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,分成以下 6 种解决方案。(一)规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。优点:解决(规避)了分布式事务。缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。由于这个方法存在明显缺点,通常不建议使用。(二)经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。eBay 方式的主要思路如下。Base:一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到 updates_applied,事务执行成功之后再删除队列。通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。(三)去哪儿网分布式事务方案随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢?最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过,使用异步消息 Consumer 端需要实现幂等。幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:重试 B,直到 B 成功,事务记录表里记录了各项调用参数等信息;执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。(四)蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?方案选型服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。(五)支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说,DTS 框架有如下特性:最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较,没有单独的 Prepare 阶段,降低协议成本。系统故障容忍度高,恢复简单(六)农信网数据一致性方案电商业务公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说,电商部门的订单支付,需要调用支付平台的支付接口来处理订单;同时需要调用积分中心的接口,按照业务规则,给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。用户信息变更公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。

小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

问题

【精品问答】带你进入数据库领域

谙忆 2020-04-07 20:45:48 12 浏览量 回答数 1

问题

常用管理函数

云栖大讲堂 2019-12-01 21:37:49 966 浏览量 回答数 0

问题

Springboot vue.js html 跨域 前后分离 shiro权限 websocket即时

游客ydre72cd7ywew 2019-12-01 20:00:40 16 浏览量 回答数 0

问题

Springboot vue.js html 跨域 前后分离 Activiti6 工作流

游客ydre72cd7ywew 2019-12-01 19:51:52 38 浏览量 回答数 0

问题

Springboot vue.js 前后分离 跨域 集成代码生成器 shiro权限

游客egqjd4t7mlyom 2019-12-01 21:49:37 40 浏览量 回答数 1

问题

Springboot vue.js html 跨域 前后分离 shiro权限 集成代码生成器

游客ydre72cd7ywew 2019-12-01 19:59:00 11 浏览量 回答数 0

问题

Springboot vue 前后分离 跨域 Activiti6 工作流 集成代码生成器 shiro

游客egqjd4t7mlyom 2019-12-01 19:53:56 49 浏览量 回答数 0

问题

Springboot vue 前后分离 跨域 Activiti6 工作流 集成代码生成器 shiro

游客ydre72cd7ywew 2019-12-01 21:49:01 85 浏览量 回答数 1

问题

Springboot vue.js html 跨域 前后分离 Activiti6 工作流 集成代码生

游客ydre72cd7ywew 2019-12-01 19:58:00 23 浏览量 回答数 0

问题

Springboot vue.js html 跨域 前后分离 Activiti6 工作流 集成代码生

游客egqjd4t7mlyom 2019-12-01 19:58:33 35 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站