• 关于

    数据库数据完整性有

    的搜索结果

问题

数据库使用外键会导致心脏不好?

今天看了开源中国的动弹,有人说数据库使用外键会导致心脏不好,然后特意百度一一下,特此记录。 摘录网上讨论共同观点: 主键和索引是不可少的,不仅可以优化数据检索速度...
小柒2012 2019-12-01 21:18:20 9240 浏览量 回答数 4

回答

同一个业务可以由不同的技术方案实现,其实我倒是建议: 1. 在系统设计期间还是采用范式设计比较好,数据模型非常清晰; 2. 在DEV环境和SIT环境中,数据库的表带有外键,如果测试非常充分,那么数据库会起到数据库完整性校验的补充作用,反过来能促进改善应用代码的数据完整性校验功能; 3. 在PRE和PRD环境中,数据库的表不带外键,此时经过前一轮的完整测试,已经能保证应用的数据完整性,这时就去掉外键保证性能 4. 有时候为了简化查询过程,有可能也需要在子表中添加一些冗余字段
xninja 2019-12-02 02:04:10 0 浏览量 回答数 0

回答

但是也有人说尽量不要去使用外键,在程序中控制数据的完整性约束性就可以了,否则不方便维护你要看是什么人说的。很多程序员的数据库水平比不上用户。这些人认为程序是万能的。很多DBA认为数据是最重要的,比程序活的长。程序不能用了,数据仍是企业的重要资产。如果不用外键,数据的完整性得不到保证。如果你觉得这样可以接受,当然可以不用外键。外键是基本的数据库约束,如果这都省略了,那你的数据库根本不能称为数据库。很多人说关系数据库性能差,其实大部分都是他们设计得差。下面谈谈很多人所说的外键的缺点。外键会带来不便比如,删一条数据出错我觉得这不是坏事,尤其是对用户来说。想想编程时,编译器也会报错,我们都知道这不是坏事,反而提前防止了错误。又比如,批量insert如果你可以肯定数据没问题,DBMS提供了忽略外键约束的选择。但是,当数据的输入来源不可靠时,很容易出现数据不一致,所以大部分时间外键(还有其他约束)是必要的。外键需要额外的开销,降低性能任何代码都有开销,关键看值不值得。什么事都不做,是最快的,根本不需要花时间。正因为数据的正确性是至关重要的,用外键当然值得。即使不用外键,你也要在程序中控制数据的正确性。所以这个开销是必须的,不能省掉的。通过程序控制数据完整性有很多缺点,比如1 程序bug基本上没有无bug的程序,这就是说,外键的功能无法可靠地被程序替代。2 数据和程序的强耦合数据库只能被一个程序使用,要支持多个程序,并且保证数据完整性,a) 要么重复逻辑每个程序自己控制数据的一致性,显然是很糟糕的。b) 要么通过共同的接口访问数据库这是比较流行的一种方法。3层架构,SOA,...我不敢说这些架构都是错误的,他们都有特定的用途。但是你要明白,一个系统越复杂,零件越多,出错的可能性就越大,而且性能也越差。总而言之,如果你认为数据正确性是必须要保证的,那么你就必须付出一定的代价来实现。用外键比用程序控制更可靠,同时更简单直接,减轻了程序的负担。DBMS有40年的历史,是顶尖的程序员用C/C++开发出来的,经过重重测试,被无数项目用到,其可靠性和性能已经接近最优状态了。你如果觉得你们项目里的程序员能做得更好,对事务、并发等技术都无比熟悉,又有充足的时间,那你们可以用程序控制。老实说,我接触的项目很多都是不用外键约束的,很多都是不考虑规范化设计的。这样的系统很复杂(没必要这么复杂),性能不好。这是我的切身体会。当然,所有事情都不能一概而论,不用外键的程序也能做得很好,卖得很好。当你做决定时,要想清楚后果。我个人倾向于经典的方法,可靠的方法。
a123456678 2019-12-02 03:02:52 0 浏览量 回答数 0

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

回答

但是也有人说尽量不要去使用外键,在程序中控制数据的完整性约束性就可以了,否则不方便维护你要看是什么人说的。很多程序员的数据库水平比不上用户。这些人认为程序是万能的。很多DBA认为数据是最重要的,比程序活的长。程序不能用了,数据仍是企业的重要资产。如果不用外键,数据的完整性得不到保证。如果你觉得这样可以接受,当然可以不用外键。外键是基本的数据库约束,如果这都省略了,那你的数据库根本不能称为数据库。很多人说关系数据库性能差,其实大部分都是他们设计得差。下面谈谈很多人所说的外键的缺点。外键会带来不便1.比如,删一条数据出错我觉得这不是坏事,尤其是对用户来说。想想编程时,编译器也会报错,我们都知道这不是坏事,反而提前防止了错误。2.又比如,批量insert如果你可以肯定数据没问题,DBMS提供了忽略外键约束的选择。但是,当数据的输入来源不可靠时,很容易出现数据不一致,所以大部分时间外键(还有其他约束)是必要的。外键需要额外的开销,降低性能任何代码都有开销,关键看值不值得。什么事都不做,是最快的,根本不需要花时间。正因为数据的正确性是至关重要的,用外键当然值得。即使不用外键,你也要在程序中控制数据的正确性。所以这个开销是必须的,不能省掉的。通过程序控制数据完整性有很多缺点,比如1 程序bug基本上没有无bug的程序,这就是说,外键的功能无法可靠地被程序替代。2 数据和程序的强耦合数据库只能被一个程序使用,要支持多个程序,并且保证数据完整性,a) 要么重复逻辑每个程序自己控制数据的一致性,显然是很糟糕的。b) 要么通过共同的接口访问数据库这是比较流行的一种方法。3层架构,SOA,...我不敢说这些架构都是错误的,他们都有特定的用途。但是你要明白,一个系统越复杂,零件越多,出错的可能性就越大,而且性能也越差。总而言之,如果你认为数据正确性是必须要保证的,那么你就必须付出一定的代价来实现。用外键比用程序控制更可靠,同时更简单直接,减轻了程序的负担。DBMS有40年的历史,是顶尖的程序员用C/C++开发出来的,经过重重测试,被无数项目用到,其可靠性和性能已经接近最优状态了。你如果觉得你们项目里的程序员能做得更好,对事务、并发等技术都无比熟悉,又有充足的时间,那你们可以用程序控制。老实说,我接触的项目很多都是不用外键约束的,很多都是不考虑规范化设计的。这样的系统很复杂(没必要这么复杂),性能不好。这是我的切身体会。当然,所有事情都不能一概而论,不用外键的程序也能做得很好,卖得很好。当你做决定时,要想清楚后果。我个人倾向于经典的方法,可靠的方法。
蛮大人123 2019-12-02 01:46:42 0 浏览量 回答数 0

回答

Android提供了SDK层的数据库API支持,其底层使用的是SQLite数据库.这里的完整概念是Android系统提供的Data持久化方案,完整文档见: https://developer.android.com/guide/topics/data/ 关于数据存储一般有如下一些需要考虑的点:持久性: 本地持久、内存持久、云端持久安全性: 整体数据的隐私性共享性: 数据在应用间、账号间的共享备份性: 目前一般需要考虑数据的云端存储存储效率与成本: 读写与编解码速度(缓存、视图等),占用硬盘空间、内存空间大小,数据规模程序的未来数据演变趋势(变更与扩容)数据增量变更与灾备方案如果使用第三方组件,需要考虑提供方的长远稳定性建议在进行持久化设计时充分考虑上述问题。
itxiaowang 2019-12-02 00:56:00 0 浏览量 回答数 0

回答

首先,我们先来聊聊各类数据模型。下列相关信息参考自Emil Eifrem的博文及NoSQL数据库说明。文档类数据库传承:受Lotus Notes启发而来。数据模型:文档汇总,包括键-值汇总。实例: CouchDB, MongoDB优势: 数据建模自然、程序员易于上手、开发流程短、兼容网页模式、便于达成CRUD(即添加、查询、更新及删除的简称)。图形类数据库传承:来自 Euler 及图形理论。数据模型:节点及关系,二者结合能够保持键-值间的成对状态实例: AllegroGraph, InfoGrid, Neo4j优势:轻松玩转复杂的图形问题、处理速度快关系类数据库传承:源自 E. F. Codd在大型共享数据库中所提出的数据关系模型理论数据模型:以关系组为基础实例: VoltDB, Clustrix, MySQL优势:性能强大、联机事务处理系统扩展性好、支持SQL访问、视图直观、擅长处理交易关系、与程序员间的交互效果优异面向对象类数据库传承:源自图形数据库方面的研究成果数据模型: 对象实例: Objectivity, Gemstone优势:擅长处理复杂的对象模型、快速的键-值访问及键-功能访问并且兼具图形数据库的各类功能键-值存储传承: Amazon Dynamo中的paper概念及分布式hash表数据模型:对成对键-值的全局化汇总实例: Membase, Riak优势:尺寸掌控得当、擅长处理持续的小规模读写需求、速度快、程序员易于上手BigTable Clones传承自:谷歌BigTable中的paper概念数据模型:纵列群,即在某个表格模型中,每行在理论上至少可以有一套单独的纵列配置实例: HBase, Hypertable, Cassandra优势:尺寸掌控得当、擅长应对大规模写入负载、可用性高、支持多数据中心、支持映射简化数据结构类服务传承: 不明实例: Redis数据模型: 执行过程基于索引、列表、集合及字符串值优势:为数据库应用引入前所未有的新鲜血液网格类数据库传承:源自数据网格及元组空间研究数据模型:基于空间的构架实例: GigaSpaces, Coherence优势:优良的性能表现及上佳的交易处理扩展性我们该为自己的应用程序选择哪套方案?选择的关键在于重新思考我们的应用程序如何依据不同数据模型及不同产品进行有针对性的协同工作。即用正确的数据模型处理对应的现实任务、用正确的产品解决对应的现实问题。要探究哪类数据模型能够切实为我们的应用程序提供帮助,可以参考“到底NoSQL能在我们的工作中发挥什么作用?”一文。在这篇文章中,我试着将各种不同特性、不同功能的常用创建系统中的那些非常规的应用实例综合起来。将应用实例中的客观需求与我们的选择联系起来。这样大家就能够逆向分析出我们的基础架构中适合引入哪些产品。至于具体结论是NoSQL还是SQL,这已经不重要了。关注数据模型、产品特性以及自身需要。产品总是将各种不同的功能集中起来,因此我们很难单纯从某一类数据模型构成方式的角度直接找到最合用的那款。对功能及特性的需求存在优先级,只要对这种优先级具备较为清晰的了解,我们就能够做出最佳选择。如果我们的应用程序需要…复杂的交易:因为没人愿意承受数据丢失,或者大家更倾向于一套简单易用的交易编程模式,那么请考虑使用关系类或网格类数据库。例如:一套库存系统可能需要完整的ACID(即数据库事务执行四要素:原子性、一致性、隔离性及持久性)。顾客选中了一件产品却被告知没有库存了,这类情况显然容易引起麻烦。因为大多数时候,我们想要的并不是额外补偿、而只是选中的那件货品。若是以扩展性为优先,那么NoSQL或SQL都能应对自如。这种情况下我们需要关注那些支持向外扩展、分类处理、实时添加及移除设备、负载平衡、自动分类及整理并且容错率较高的系统。要求持续保有数据库写入功能,则需要较高的可用性。在这种情况下不妨关注BigTable类产品,其在一致性方面表现出众。如有大量的小规模持续读写要求,也就是说工作负载处于波动状态,可以关注文档类、键-值类或是那些提供快速内存访问功能的数据库。引入固态硬盘作为存储媒介也是不错的选择。以社交网络为实施重点的话,我们首先想到的就是图形类数据库;其次则是Riak这种关系类数据库。具备简单SQL功能的常驻内存式关系数据库基本上就可以满足小型数据集合的需求。Redis的集合及列表操作也能发挥作用。如果我们的应用程序需要…在访问模式及数据类型多种多样的情况下,文档类数据库比较值得考虑。这类数据库不仅灵活性好,性能表现也可圈可点。需要完备的脱机报告与大型数据集的话,首选产品是Hadoop,其次则是支持映射简化的其它产品。不过仅仅支持映射简化还不足以提供如Hadoop一样上佳的处理能力。如果业务跨越数个数据中心,Bigtable Clone及其它提供分布式选项的产品能够应对由地域距离引起的延迟现象,并具备较好的分区兼容性。要建立CRUD应用程序,首选文档类数据库。这类产品简化了从外部访问复杂数据的过程。需要内置搜索功能的话,推荐Riak。要对数据结构中的诸如列表、集合、队列及发布/订阅信息进行操作,Redis是不二之选。其具备的分布式锁定、覆盖式日志及其它各种功能都会在这类应用状态下大放异彩。将数据以便于处理的形式反馈给程序员(例如以JSON、HTTP、REST、Javascript这类形式),文档类数据库能够满足这类诉求,键-值类数据库效果次之。如果我们的应用程序需要…以直观视图的形式进行同步交易,并且具备实时数据反馈功能,VoltDB算得上一把好手。其数据汇总以及时间窗口化的表现都非常抢眼。若是需要企业级的支持及服务水平协议,我们需要着眼于特殊市场。Membase就是这样一个例子。要记录持续的数据流,却找不到必要的一致性保障?BigTable Clone交出了令人满意的答卷,因为其工作基于分布式文件系统,所以可以应对大量的写入操作。要让操作过程变得尽可能简单,答案一定在托管或平台即服务类方案之中。它们存在的目的正是处理这类要求。要向企业级客户做出推荐?不妨考虑关系类数据库,因为它们的长项就是具备解决繁杂关系问题的技术。如果需要利用动态方式建立对象之间的关系以使其具有动态特性,图形类数据库能帮上大忙。这类产品往往不需要特定的模式及模型,因此可以通过编程逐步建立。S3这类存储服务则是为支持大型媒体信息而生。相比之下NoSQL系统则往往无法处理大型二进制数据块,尽管MongoDB本身具备文件服务功能。如果我们的应用程序需要…有高效批量上传大量数据的需求?我们还是得找点有对应功能的产品。大多数产品都无法胜任,因为它们不支持批量操作。文档类数据库或是键-值类数据库能够利用流畅的模式化系统提供便捷的上传途径,因为这两类产品不仅支持可选区域、添加区域及删除区域,而且无需建立完整的模式迁移框架。要实现完整性限制,就得选择一款支持SQL DLL的产品,并在存储过程或是应用程序代码中加以运行。对于协同工作极为依赖的时候就要选择图形类数据库,因为这类产品支持在不同实体间的迅速切换。数据的移动距离较短且不必经过网络时,可以在预存程序中做出选择。预存程序在关系类、网格类、文档类甚至是键-值类数据库中都能找到。如果我们的应用程序需要…键-值存储体系擅长处理BLOB类数据的缓存及存储问题。缓存可以用于应对网页或复杂对象的存储,这种方案能够降低延迟、并且比起使用关系类数据库来说成本也较低。对于数据安全及工作状态要求较高的话可以尝试使用定制产品,并且在普遍的工作范畴(例如向上扩展、调整、分布式缓存、分区及反规范化等等)之外一定要为扩展性(或其它方面)准备解决方案。多样化的数据类型意味着我们的数据不能简单用表格来管理或是用纵列来划分,其复杂的结构及用户组成(也可能还有其它各种因素)只有文档类、键-值类以及Bigtable Clone这些数据库才能应付。上述各类数据库都具备极为灵活的数据类型处理能力。有时其它业务部门会需要进行快速关系查询,引入这种查询方式可以使我们不必为了偶尔的查看而重建一切信息。任何支持SQL的数据库都能实现这类查询。至于在云平台上运行并自动充分利用云平台的功能——这种美好的愿望目前还只能是愿望。如果我们的应用程序需要…支持辅助索引,以便通过不同的关键词查找数据,这要由关系类数据库及Cassandra推出的新辅助索引系统共同支持才能实现。创建一套处于不断增长中的数据集合(真正天文数量级的数据)然而访问量却并不大,那么Bigtable Clone是最佳选择,因为它会将数据妥善安排在分布式文件系统当中。需要整合其它类型的服务并确保数据库提供延后写入同步功能?那最好的实现方式是捕捉数据库的各种变化并将其反馈到其它系统中以保障运作的一致性。通过容错性检查了解系统对供电中断、隔离及其它故障情况的适应程度。若是当前的某项技术尚无人问津、自己却感觉大有潜力可挖,不妨在这条路上坚持走下去。这种情况有时会带来意料之外的美好前景。尝试在移动平台上工作并关注CouchDB及移动版couchbase。哪种方案更好?25%的状态改善尚不足以让我们下决心选择NoSQL。选择标准是否恰当取决于实际情况。这类标准对你的方案有指导意义吗?如果你的公司尚处于起步阶段,并且需要尽快推出自己的产品,这时不要再犹豫不决了。无论是SQL还是NoSQL都可以作为参考。
a123456678 2019-12-02 03:00:14 0 浏览量 回答数 0

回答

三个字,不可能######回复 @DanceCoder : 没有这种数据库管理员,如果是系统里的管理员,倒是可以通过系统代码,实现管理员只能管理不能查看的逻辑。数据库本身的管理员不行,除非让数据库管理员都进不了数据库,那还管理啥。######回复 @乌龟壳 : 面试官说可以执行增删改查,就是直接在控制台执行SQL语句的那种。######回复 @HankeBoom : 如果有背景就可能不一样,比如说的其实是所谓的数据库管理员之类的,就看看服务器状态那些,数据库都没权限进去######哈哈哈,面试官好坏。。。。。######你确认他不是在出脑筋急转弯? ######不知道,根据我仅有的面试经验,一般都是先问一些基础的问题。我也不知道他为什么问这么摸不着头脑的问题。难道是在考察我的解决问题能力?###### 数据库管理员没有权限看数据库,感觉就像厨师不能进厨房一样。######面试官的意思是不要在管理员权限方面限制不同权限级别的管理员###### 在java程序是对用户名和密码进行了加密后存入数据库的,登录的时候时候再提取数据库的数据进行相反的解密过程,如果一致,才通过 根据你的描述,管理员A又可以管理服务器后台,又可以管理数据库,那只能说明管理员只能为一个(多了就权责不分了),当然最好的是 不要给A日志信息查看权限,要不然就他就可以做到天衣无缝。 以上是个人对数据安全性的理解 下面废话:1:不考虑数据库权限、不考虑加密、不考虑数据库类型,说明数据库安全性有问题。2:面试官的回答“登录修改用户密码和然后就可以登录了。” ,有点sb思维,我都看得到密码了,还用修改后台的密码,还要脱裤子放屁(多此一举) ######哈哈哈,面试官确实好坏###### 这种东西只有在登录的时候处理吧. 数据库都是持久性的东西, 不管如何加密. 只要修改成一个我知道的明文加密的数据不就行了? 所以,还是在登录的后台做处理. 比如加密的是根据用户输入的密码加上用户名之类的处理过的密码. 那么数据库管理员不知道后台的处理逻辑, 修改了数据库也无用. ######长知识了,谢谢######66666###### 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 ######就是性能堪忧######这个有点厉害啊###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 可是都说了不允许加密了,实在想不出不加密怎么办了######你需要了解MySQL的“视图”是干嘛的。。。。。。。######视图不是也可以执行改数据操作吗###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 引用来自“钛元素”的评论可是都说了不允许加密了,实在想不出不加密怎么办了 上面的加密只是为了去掉多个片段记录中用户名的相关性,让管理员无法通过搜索找出所有和这个用户名相关的记录项,不需要解密,只是一种变换算法。
kun坤 2020-06-08 10:04:20 0 浏览量 回答数 0

问题

外键在电商网站数据库设计中用的多不多啊?

外键在电商网站数据库设计中用的多不多啊?比如用在一些关联表上,感觉很实用,保证了不会产生错误的数据行,和无用的数据行,但是也有人说尽量不要去使用外键,在程序中控制数据的完整性约束性就可以了,否则不方便维护,我也不知道到底怎么样好。...
a123456678 2019-12-01 20:16:15 737 浏览量 回答数 1

问题

外键在电商网站数据库设计中用的多不多啊?

外键在电商网站数据库设计中用的多不多啊?比如用在一些关联表上,感觉很实用,保证了不会产生错误的数据行,和无用的数据行,但是也有人说尽量不要去使用外键,在程序中控制数据的完整性约束性就可以了,否则不方便维护,我也不知道到底怎么样好。...
蛮大人123 2019-12-01 19:53:28 1341 浏览量 回答数 1

问题

预检查的内容及失败时的修复方式有什么

实时同步链路在启动之前,会先进行简单的预检查,本小节简单介绍预检查的内容及失败时的修复方式。 预检查项说明 源库连接性检查 检查内容这个检查项主要检查数据传输服务器同源RDS实例的连接性。数据传输...
云栖大讲堂 2019-12-01 21:25:12 1282 浏览量 回答数 0

问题

预检查的内容及失败时的修复方式有什么

实时同步链路在启动之前,会先进行简单的预检查,本小节简单介绍预检查的内容及失败时的修复方式。 预检查项说明 源库连接性检查 检查内容这个检查项主要检查数据传输服务器同源RDS实例的连接性。数据传输...
云栖大讲堂 2019-12-01 21:25:13 1111 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档使用 数据传输 DTS 可以将本地 PostgreSQL 数据库实例的数据迁移到 RDS for PostgreSQL 实例。PostgreSQL 迁移支持增量数据同步功能,可以实现在本地应用不停服的情况下,平滑完成 PostgreSQL 数据库的迁移工作。 本小节简单介绍使用 数据传输 DTS (以下简称 DTS)进行 PostgreSQL->RDS for PostgreSQL 数据迁移的任务配置流程。 迁移类型简介 结构迁移 DTS 将被迁移对象的结构定义迁移到目标实例。对于 PostgreSQL,DTS 支持结构迁移的对象包含:Table、trigger、view、sequence、function、user defined type、rule、domain、operation、aggregate。 全量数据迁移 DTS 将源数据库迁移对象的存量数据全部迁移到目标实例。 增量数据迁移 增量数据迁移将迁移过程中,本地 PostgreSQL 数据库实例的增量更新数据同步到目标 RDS for PostgreSQL 实例,最终实现本地 PostgreSQL 数据库实例同目标 RDS for PostgreSQL 实例保持动态数据同步的过程。使用增量数据迁移,可以实现在本地 PostgreSQL 数据库实例正常提供服务的同时,平滑完成本地 PostgreSQL->RDS For PostgreSQL 的数据迁移。 迁移限制 全量迁移支持的 PostgreSQL 版本为:9.2、9.3、9.4、9.5 及以上版本;增量迁移支持的源实例 PostgreSQL 版本:9.4.8、9.5 及以上版本。迁移过程中,不支持 DDL 操作。不支持迁移使用 C 语言编写的 function。如果使用了对象名映射功能后,依赖这个对象的其他对象可能迁移失败。 迁移权限要求当使用数据传输服务进行 PostgreSQL 迁移时,在不同迁移类型情况下,源跟目标数据库的迁移帐号权限要求如下: 迁移类型 结构迁移 全量迁移 增量数据迁移 本地 PostgreSQL 实例 pg_catalog 的 usage 权限 迁移对象的 select superuser 目标 RDS for PostgreSQL 实例 迁移对象的 create、usage 权限 schema 的 owner schema 的 owner 迁移顺序DTS 在进行 PostgreSQL->RDS For PostgreSQL 数据迁移时,为了解决对象间的依赖,提高迁移成功率。结构对象及数据的迁移顺序如下: 进行结构对象:Table、view、sequence、function、user defined type、rule、domain、operation、aggregate 的迁移全量数据迁移进行结构对象:trigger、foreign key 的迁移 全量数据迁移完成后,任务列表中的迁移进度为:结构迁移 100%,全量迁移 100%,迁移状态为“迁移中”,此时迁移任务正在进行步骤(3)中的对象的迁移。此时,请勿手动结束任务,否则会造成迁移数据丢失。待迁移状态显示为“迁移完成”后,表示全量数据迁移任务已经完成,这时可以安全地手动结束任务。 迁移步骤下面详细介绍下使用 DTS 将本地的 PostgreSQL 数据库迁移到 RDS for PostgreSQL 的任务配置流程。 RDS实例数据库创建在数据迁移过程中,如果待迁移的数据库在目标 RDS for PostgreSQL 实例中不存在,那么 DTS 自动会创建。但是对于如下两种情况,用户需要在配置迁移任务之前,手动创建数据库。 数据库名称不符合:RDS 定义规范(由小写字母、数字、下划线、中划线组成,字母开头,字母或数字结尾,最长 64 个字符)。待迁移数据库,在本地 PostgreSQL 数据库实例和目标 RDS for PostgreSQL 实例中存储名称不同。 对于这两种情况,用户需要在配置迁移任务之前,先在 RDS 控制台完成数据库创建。具体参考RDS数据库创建流程。 迁移帐号创建迁移任务配置,需要提供 PostgreSQL 数据库实例及目标 RDS for PostgreSQL 实例的迁移账号。迁移账号所需权限详见上文的 迁移权限要求。 如果您的本地 PostgreSQL 数据库实例或 RDS for PostgreSQL 实例的迁移账号尚未创建,那么可以参考如下流程创建迁移账号: 通过 PostgreSQL 客户端,在 PostgreSQL 中创建迁移账号。 create user username password 'password' 如果您要使用增量迁移,那么创建的账号必须是 superuser,所以创建账号语句调整为: create user username with superuser password 'password' 参数说明: username:要创建的账号名password:该账号的登录密码 给迁移账号授权,本地 PostgreSQL 数据库实例及 RDS For PostgreSQL 实例的迁移账号权限要求详见上表。 GRANT privileges ON tablename TO username; 参数说明: privileges:该账号的操作权限,如 SELECT、INSERT、UPDATE 等。如果要授权该账号所有权限,则使用 ALLtablename:表名。如果要授权该账号所有的表权限,则使用通配符 *username:要授权的账号名 逻辑流复制插件安装如果您需要使用增量数据迁移进行不停机迁移,那么在任务配置之前,需要在本地 PostgreSQL 中安装 DTS 提供的逻辑流复制插件。 插件下载。 PostgreSQL 9.4 版本 PostgreSQL 9.5 版本 PostgreSQL 9.6版本 PostgreSQL 10.0版本 插件安装。 解压下载的压缩包。将 ali_decoding.so 文件拷贝到 PostgreSQL 安装路径的 lib 目录下。 如果用 rpm 包安装,那么这个绝对路径为:/usr/pgsql-{$version}/lib/,其中 $version 为版本号,例如如果版本为 9.5,那么绝对路径为:/usr/pgsql-9.5/lib。 将ali_decoding.contorl 文件拷贝到 PostgreSQL 安装路径下的share/extension 目录下。 如果用 rpm 包安装,那么这个绝对路径为:/usr/pgsql-${version}/share/extension/,其中 ${version}为 PostgreSQL 版本号,例如如果版本为 9.5,那么绝对路径为:/usr/pgsql-9.5/share/extension/。 测试安装是否成功。 使用 superuser 账号登录 PostgreSQL 客户端,运行如下 SQL,看是否能够成功创建 replication slot 。如果成功创建那么说明插件安装成功。 SELECT * FROM pg_create_logical_replication_slot('replication_slot_test', 'ali_decoding'); 如果输出结果如下,说明插件安装成功。 测试成功后,使用如下 SQL 将 replication slot 删除掉。 SELECT pg_drop_replication_slot('replication_slot_test'); 迁移任务配置当上面的所有前置条件都配置完成后,就可以开始正式的数据迁移了。下面详细介绍迁移任务配置流程。 进入数据传输 DTS 控制台,点击右上角的创建迁移任务,开始迁移任务配置。本地 PostgreSQL 数据库实例跟目标 RDS for PostgreSQL 实例连接信息配置。 这个步骤主要配置 迁移任务名称,本地 PostgreSQL 数据库实例连接信息及目标 RDS for PostgreSQL 实例连接信息。其中: 任务名称 DTS 为每个任务自动生成一个任务名称,任务名称没有唯一性要求。您可以根据需要修改任务名称,建议为任务配置具有业务意义的名称,便于后续的任务识别。 源实例信息 实例类型:选择 有公网 IP 的自建数据库 数据库类型: 选择 PostgreSQL主机名或IP地址: 配置本地 PostgreSQL 数据库实例的访问地址,这个地址必须为公网访问方式端口:本地 PostgreSQL 数据库实例的监听端口数据库名称:连接本地 PostgreSQL 数据库实例的默认数据库名数据库账号:本地 PostgreSQL 数据库实例的连接账号数据库密码:本地 PostgreSQL 数据库实例连接账号对应的密码 目标实例信息 实例类型:选择 RDS 实例RDS 实例 ID: 配置迁移的目标 RDS for PostgreSQL 实例的实例 ID。 DTS 支持经典网络和 VPC 网络的 RDS for PostgreSQL 实例数据库名称:连接 RDS for PostgreSQL 实例的默认数据库名数据库账号:RDS For PostgreSQL 实例的连接账号数据库密码:上面指定的 RDS for PostgreSQL 实例连接账号对应的密码 当配置完连接信息后,点击右下角 授权白名单 并进入下一步进行白名单授权。这个步骤 DTS 会将 DTS 服务器的 IP 地址添加到目标 RDS 实例的白名单中,避免因为 RDS 实例设置了白名单,导致 DTS 服务器连接不上 RDS for PostgreSQL 实例导致迁移失败。 选择迁移对象及迁移类型。 迁移类型 对于 PostgreSQL->RDS for PostgreSQL,支持 结构迁移、全量数据迁移、增量数据迁移。 如果只需要进行全量迁移,那么迁移类型选择:结构迁移 + 全量数据迁移。 如果需要进行不停机迁移,那么迁移类型选择:结构迁移 + 全量数据迁移+增量数据迁移。 迁移对象 选择您要迁移的对象。迁移对象选择的粒度可以为:库、表、列三个粒度。默认情况下,对象迁移到 RDS for PostgreSQL 实例后,对象名跟本地 PostgreSQL 数据库实例一致。如果您迁移的对象在源实例跟目标实例上名称不同,那么需要使用 DTS 提供的对象名映射功能,详细使用方式可以参考库表列映射。 预检查。 在迁移任务正式启动之前,会先进行前置预检查,只有预检查通过后,才能成功启动迁移。预检查的内容及修复方式可以参考本文末尾的 预检查简介 一节。 如果预检查失败,那么可以点击具体检查项后的按钮,查看具体的失败详情,并根据失败原因修复后,重新进行预检查。 启动迁移任务。 当预检查通过后,可以启动迁移任务,任务启动成功后,可以在任务列表中查看迁移的具体状态及迁移进度。 至此,完成本地 PostgreSQL 数据库实例到 RDS for PostgreSQL 实例的数据迁移任务配置。 预检查内容DTS 在启动迁移之前,会进行前置预检查,本小节简单介绍 PostgreSQL->RDS for PostgreSQL 的预检查内容: 预检查项 检查内容 备注 源库连接性检查 检查 DTS 服务同本地 PostgreSQL 数据库 实例的连通性 (1) 填写信息是否有误?如果填写信息有误,请修改后重新预检查(2) 检查端口是否配置从其他服务器连接 目的库连接性检查 检查 DTS 服务同目的 RDS for PostgreSQL 实例的连通性 检查填写信息是否有误,如果有误请先修改后重新预检查 源库版本检查 检查本地 PostgreSQL 数据库实例版本跟目标 RDS for PostgreSQL 是否一致 如果版本不一致,预检查会有提醒。可以根据提醒对本地 PostgreSQL 数据库实例进行升级或降级,也可以继续迁移 数据库可用性检查 检查待迁移数据库在目标 RDS for PostgreSQL 实例是否已存在 如果待迁移数据库命名规范不满足 RDS 实例要求,那么 DTS 在目标 RDS for PostgreSQL 实例创建待迁移数据库会报错失败,即数据库可用性检查会失败。此时可以参考 库表列映射 对迁移数据库进行重命名 源库权限检查 检查任务配置时,提供的本地 PostgreSQL 数据库实例的账号的权限是否满足要求 如果检查失败,那么请参考本文 迁移账号创建 一节对迁移账号进行授权后,重新进行预检查 目的库权限检查 检查任务配置时,提供的目的 RDS for PostgreSQL 数据库账号的权限是否满足要求 如果检查失败,那么请参考本文 迁移账号创建 一节对迁移账号进行授权后,重新进行预检查 同名对象存在性检查 检查待迁移对象在目标 RDS for PostgreSQL 实例中是否已经存在 如果检查失败,请将目标库中这些已经存在的对象删除后,重新进行预检查 源端同名对象存在性检查 检查要迁移到同一个数据库中的多个对象是否重名 如果检查失败,可以参考 库表列映射 将重名对象进行重命名 约束完整性检查 检查待迁移对象依赖的父对象是否迁移 如果检查失败,那么可以修改迁移对象,同时迁移依赖的父对象后,重新预检查 增量拓扑冲突检查 检查同一个迁移对象是否已经存在迁移链路 如果存在冲突链路,那么需要删除掉冲突链路后,重新预检查 LC_MONETERY 一致性检查 检查源库、目标库的 Lc_monetery 定义是否一致 如果检查失败,可以修改目标 RDS For PostgreSQL 实例的 LC_MONETERY 定义,或者继续迁移 PostgreSQL 逻辑流复制插件检查 检查本地 PostgreSQL 实例是否安装了逻辑流复制插件 如果检查失败,可以参考下面的 逻辑流复制插件安装 一节安装逻辑流复制插件后重新预检查 PostgreSQL 逻辑流 slot 存在性检查 检查本地 PostgreSQL 数据库实例存在跟 DTS 创建的 replication slot 重名的 replication slot 如果检查失败,可以删除本地 PostgreSQL 数据库实例中已经存在的同名 replication slot 后,重新预检查
2019-12-01 23:09:43 0 浏览量 回答数 0

回答

简单的来说,我给你举两个例子: 1、对数据库做了ddl的操作,但是没有进行提交操作,此时就会提示受影响行数,如果最后没有进行提交操作,数据就会回滚。 2、对数据进行操作时,如果数据报错,如批量插入数据,其中有一条无法插入,那么此次的操作就会被视为无效,数据库就会回滚,以保证数据的完整性。 3、在程序开发时,是以事务为原子性操作的,此时可能因为一个业务操作会对数据库的多个表进行增删改,如果中间出现问题,那么对已操作部分的数据怎么办呢? 数据库的回滚就可以解决。 答案来源于网络
养狐狸的猫 2019-12-02 03:06:48 0 浏览量 回答数 0

回答

本文介绍如何使用数据传输服务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

问题

金融版

产品简介 金融版(原名:三节点企业版)是阿里云关系型数据库RDS面向高端企业级用户推出的一款完全自研的云数据库系列。目前,金融版仅支持MySQL 5.6版本的实例,除...
云栖大讲堂 2019-12-01 21:35:10 879 浏览量 回答数 0

回答

数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。乐观并发控制(乐观锁)和悲观并发控制(悲观锁)是并发控制主要采用的技术手段。 悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。在查询完数据的时候就把事务锁起来,直到提交事务。实现方式:使用数据库中的锁机制 乐观锁:假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。在修改数据的时候把事务锁起来,通过version的方式来进行锁定。实现方式:乐一般会使用版本号机制或CAS算法实现。 两种锁的使用场景 从上面对两种锁的介绍,我们知道两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下(多读场景),即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。 但如果是多写的情况,一般会经常产生冲突,这就会导致上层应用会不断的进行retry,这样反倒是降低了性能,所以一般多写的场景下用悲观锁就比较合适。
剑曼红尘 2020-03-31 11:04:46 0 浏览量 回答数 0

问题

如何配置备份实例

在完成初始配置之后,就可以开始配置备份实例了。 购买实例 公测期间,通过审核的用户可以免费购买备份实例。购买页面: https://common-buy.aliyun.com/?commod...
云栖大讲堂 2019-12-01 21:32:10 1202 浏览量 回答数 0

问题

从数据迁移测试小结看,黑盒测试与灰盒测试

最近在测试公司的一个数据迁移项目,该数据迁移主要是实现将旧系统中的数据准确的迁移到新系统中,开始开发并未给具体的需求说明,按照以往的测试,我们按照黑盒测试的原理从界面上模拟构 造各个模...
技术小菜鸟 2019-12-01 21:48:13 2814 浏览量 回答数 1

回答

本文介绍如何使用数据传输服务DTS(Data Transmission Service),将自建MySQL迁移至RDS MySQL实例。DTS支持结构迁移、全量数据迁移以及增量数据迁移,同时使用这三种迁移类型可以实现在自建应用不停服的情况下,平滑地完成自建MySQL数据库的迁移上云。 前提条件 创建RDS MySQL实例。 自建MySQL数据库版本为5.1、5.5、5.6、5.7、8.0版本。 RDS MySQL实例的存储空间须大于自建MySQL数据库占用的存储空间。 注意事项 DTS在执行全量数据迁移时将占用源库和目标库一定的读写资源,可能会导致数据库的负载上升,在数据库性能较差、规格较低或业务量较大的情况下(例如源库有大量慢SQL、存在无主键表或目标库存在死锁等),可能会加重数据库压力,甚至导致数据库服务不可用。因此您需要在执行数据迁移前评估源库和目标库的性能,同时建议您在业务低峰期执行数据迁移(例如源库和目标库的CPU负载在30%以下)。 如果源数据库没有主键或唯一约束,且所有字段没有唯一性,可能会导致目标数据库中出现重复数据。 对于数据类型为FLOAT或DOUBLE的列,DTS会通过ROUND(COLUMN,PRECISION)来读取该列的值。如果没有明确定义其精度,DTS对FLOAT的迁移精度为38位,对DOUBLE的迁移精度为308位,请确认迁移精度是否符合业务预期。 DTS自动在阿里云RDS MySQL中创建数据库,如果待迁移的数据库名称不符合阿里云RDS的定义规范,将导致创建数据库失败,所以您需要在配置迁移任务之前在阿里云RDS MySQL中创建数据库。 说明 关于阿里云RDS的定义规范和创建数据库的操作方法,请参见创建数据库。 对于迁移失败的任务,DTS会触发自动恢复。在您将业务切换至目标实例前,请务必先结束或释放该任务,避免该任务被自动恢复后,导致源端数据覆盖目标实例的数据。 费用说明 迁移类型 链路配置费用 公网流量费用 结构迁移/全量数据迁移 不收费。 通过公网将数据迁移出阿里云时将收费,详情请参见产品定价。 增量数据迁移 收费,详情请参见产品定价。 迁移类型说明 结构迁移 DTS将迁移对象的结构定义迁移到目标实例,目前DTS支持结构迁移的对象为表、视图、触发器、存储过程、存储函数,不支持event的结构迁移。 说明 在结构迁移时,DTS会将视图、存储过程和函数中的DEFINER转换为INVOKER。 由于DTS不迁移user信息,因此在调用目标库的视图、存储过程和函数时需要对调用者授予读写权限。 全量数据迁移 DTS会将自建MySQL数据库迁移对象的存量数据,全部迁移到目标RDS MySQL实例数据库中。 说明 由于全量数据迁移会并发INSERT导致目标实例的表存在碎片,全量迁移完成后目标实例的表空间会比源实例大。 为保障数据一致性,全量数据迁移期间请勿在自建MySQL数据库中写入新的数据。 增量数据迁移 在全量迁移的基础上,DTS会读取自建MySQL数据库的binlog信息,将自建MySQL数据库的增量更新数据同步到目标RDS MySQL实例中。通过增量数据迁移可以实现在自建应用不停服的情况下,平滑地完成MySQL数据库的迁移上云。 增量数据迁移支持同步的SQL操作 INSERT、UPDATE、DELETE、REPLACE CREATE TABLE、ALTER TABLE、RENAME TABLE、TRUNCATE TABLE、DROP TABLE 数据库账号的权限要求 数据库 结构迁移 全量迁移 增量迁移 自建MySQL数据库 select权限 select权限 select、replication slave和replication client权限 RDS MySQL实例 读写权限 读写权限 读写权限 数据库账号创建及授权方法: 自建MySQL数据库请参见为自建MySQL创建账号并设置binlog。 RDS MySQL实例请参见创建账号和修改账号权限。 准备工作 为自建MySQL创建账号并设置binlog 操作步骤 登录数据传输控制台。 在左侧导航栏,单击数据迁移。 在迁移任务列表页面顶部,选择迁移的目标实例所属地域。选择地域 单击页面右上角的创建迁移任务。 配置迁移任务的源库及目标库信息。 源库和目标库连接配置 类别 配置 说明 任务名称 - DTS会自动生成一个任务名称,建议配置具有业务意义的名称(无唯一性要求),便于后续识别。 源库信息 实例类型 您可以根据源库部署位置,选择有公网IP的自建数据库、ECS上的自建数据库或通过专线/VPN网关/智能网关接入的自建数据库。 本文以有公网IP的自建数据库为例介绍配置流程,当自建MySQL数据库为其他实例类型时,配置流程与该案例类似。 实例地区 当实例类型选择为有公网IP的自建数据库时,实例地区无需设置。 说明 如果您的自建MySQL数据库具备白名单安全设置,您需要在实例地区配置项后,单击获取DTS IP段来获取到DTS服务器的IP地址,并将获取到的IP地址加入自建MySQL数据库的白名单安全设置中。 数据库类型 选择MySQL。 主机名或IP地址 填入自建MySQL数据库的访问地址,本案例中填入公网地址。 端口 填入自建MySQL数据库的服务端口(需开放至公网),默认为3306。 数据库账号 填入自建MySQL的数据库账号,权限要求请参见数据库账号的权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 源库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的源库信息是否正确。源库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的源库信息。 目标库信息 实例类型 选择RDS实例。 实例地区 选择目标RDS实例所属地域。 RDS实例ID 选择目标RDS实例ID。 数据库账号 填入目标RDS实例的数据库账号,权限要求请参见数据库账号的权限要求。 数据库密码 填入该数据库账号对应的密码。 说明 目标库信息填写完毕后,您可以单击数据库密码后的测试连接来验证填入的目标库信息是否正确。目标库信息填写正确则提示测试通过;如果提示测试失败,单击测试失败后的诊断,根据提示调整填写的目标库信息。 连接方式 根据需求选择非加密连接或SSL安全连接。如果设置为SSL安全连接,您需要提前开启RDS实例的SSL加密功能,详情请参见设置SSL加密。 配置完成后,单击页面右下角的授权白名单并进入下一步。 说明 此步骤会将DTS服务器的IP地址自动添加到目标RDS实例的白名单中,用于保障DTS服务器能够正常连接目标RDS实例。 选择迁移对象及迁移类型。 选择迁移类型和迁移对象 配置 说明 迁移类型 如果只需要进行全量迁移,则同时勾选结构迁移和全量数据迁移。 说明 为保障数据一致性,全量数据迁移期间请勿在自建MySQL数据库中写入新的数据。 如果需要进行不停机迁移,则同时勾选结构迁移、全量数据迁移和增量数据迁移。 迁移对象 在迁移对象框中单击待迁移的对象,然后单击向右小箭头将其移动至已选择对象框。 说明 迁移对象选择的粒度可以为库、表、列三个粒度。 默认情况下,迁移完成后,迁移对象名跟自建MySQL数据库一致。如果您需要迁移对象在目标RDS实例上名称不同,那么需要使用DTS提供的对象名映射功能。使用方法请参见库表列映射。 如果使用了对象名映射功能,可能会导致依赖这个对象的其他对象迁移失败。 单击页面右下角的预检查并启动。 说明 在迁移任务正式启动之前,会先进行预检查。只有预检查通过后,才能成功启动迁移任务。 如果预检查失败,单击具体检查项后的提示,查看失败详情。根据提示修复问题后,重新进行预检查。 预检查通过后,单击下一步。 在购买配置确认页面,选择链路规格并勾选数据传输(按量付费)服务条款。 单击购买并启动,迁移任务正式开始。 结束迁移任务 警告 为尽可能地减少数据迁移对业务的影响,建议参考业务切换流程文档中介绍的流程执行业务切换并建立回退方案(将目标库的增量数据实时迁移回源库中)。如果无需切换业务,则可按照下述步骤结束迁移任务。 全量数据迁移 请勿手动结束迁移任务,否则可能导致数据不完整。您只需等待迁移任务完成即可,迁移任务会自动结束。 增量数据迁移 迁移任务不会自动结束,您需要手动结束迁移任务。 观察迁移任务的进度变更为增量迁移,并显示为无延迟状态时,将源库停写几分钟,此时增量迁移的状态可能会显示延迟的时间。 等待迁移任务的增量迁移再次进入无延迟状态后,手动结束迁移任务。结束增量迁移任务 后续操作 用于数据迁移的数据库账号拥有读写权限,为保障数据库安全性,请在数据迁移完成后,删除自建MySQL数据库和RDS MySQL实例中的数据库账号。 常见问题 Q:预检查失败如何处理? A:详情请参见源库连接性检查。 Q:迁移失败的任务如何处理? A:详情请参见修复迁移失败的任务。
游客yl2rjx5yxwcam 2020-03-08 14:03:52 0 浏览量 回答数 0

回答

web数据集成技术可以从web上自动获取数据,但是获取的信息存在着大量的脏数据,比如滥用缩写词,惯用语,数据输入错误,重复记录,丢失值,拼写变化,不同的计量单位。这些数据是没有意义的,根本就不可能为以后的数据挖掘决策分析提供任何支持。数据清洗主要是提高数据的可用性,目前,数据清洗主要应用于三个领域: 1 数据仓库(DW) 2数据库中的知识发现(KDD) 3数据质量管理(TDQM) 我在公司里的第一个项目就是数据质量管理,在这里在说下数据质量管理: 通过制定、实施数据质量检核,暴露各系统数据质量问题。持续监控各系统数据质量波动情况及数据质量规则占比分析,定期生成各系统关键数据质量报告,掌握系统数据质量状况。结合系统提供的清洗组件以及数据质量问题处理流程为各系统数据质量提升提供有效支撑。数据质量(DataQuality)管理是贯穿数据生命周期的全过程,覆盖质量评估,数据去噪,数据监控,数据探查,数据清洗,数据诊断等方面。数据度量和变化频度提供了衡量数据质量好坏的手段。数据度量主要包括完整性、唯一性、一致性、准确性、合法性。变化频度主要包括业务系统数据的变化周期和实体数据的刷新周期。数据质量管理准则包括测量、提高组织数据的质量和整合性的方法。数据质量处理包括数据标准化、匹配、生存和质量监测。数据必须具备适当的质量,以解决业务要求问题。 结合大数据的参考框架及数据处理实际需求情况,数据质量管理系统主要功能定位为:数据发现、质量管理、元数据、主数据管理和信息政策管理。在数据生命周期中,数据的获取和使用周期包括系列活动:评估,分析,调整,丢弃数据,目前数据清洗的模型: 基于粗糙集理论数据清洗 基于聚式模式数据清洗 基于模糊匹配数据清洗模型 基于遗传神经网络数据清洗 基于专家系统体系结构等数据校验及转换 数据校验的目的是确保抽取数据本身的正确性和完整性, 数据转换的目的是保证数据的一致性数据清洗流程1数据预处理: 包括数据元素化,保准化 2确定清洗方法: 3校验清洗方法:先验证所用的清洗方法是否合适,抽取小样本进行验证,判断其召回率和准确率 4执行清洗工具: 5数据归档:将新旧数据源进行归档处理,方便以后的清洗一般情况下,模式中反应的元数据对应判断一个数据源的质量远远不够,因此通过具体实例来获得有关数据熟悉和不寻常模式的元数据很重要。这些元数据可以帮助发现数据质量问题,也有助于发现属性间的依赖关系,
xuning715 2019-12-02 01:12:15 0 浏览量 回答数 0

回答

看下 RDS for MySQL默认关闭MyISAM引擎 - 云数据库 RDS 版 MyISAM 引擎表不支持事务,读写操作会相互冲突,仅支持表级别锁。当其上的查询或者写入操作时间比较长的时候,会阻塞其他操作,容易导致连接堆积,而且在crash 后存在数据丢失的风险,因此 RDS   for   MySQL推荐使用 Innodb   引擎。目前 RDS  ... 来自:   帮助  >  云数据库 RDS 版  >  技术运维问题  >  MYSQL使用 为什么 RDS for MySQL 不支持 MyISAM 引擎? - 云数据库 RDS 版 RDS   for   MySQL  不支持   MyISAM   引擎的主要原因有如下几个:   MyISAM  对数据完整性的保护存在缺陷,且这些缺陷会导致数据库数据的损坏甚至丢失。另外,这些缺陷很多是设计问题,无法在不破坏兼容性的前提下修复。   MyISAM  在出现数据 ... 来自:   帮助  >  云数据库 RDS 版  >  常见问题  >  功能/付费方式
火蓝云 2019-12-02 00:31:49 0 浏览量 回答数 0

问题

大型网站数据库解决方案

对于大型网站系统而言,有三个难以逾越的难题: 1、数据资源已近乎等同生存资本,如何保障网站数据不丢失? 2、网站业务停服带来巨大经济损失,如何构建多级高可用ÿ...
rds-pd 2019-12-01 21:53:32 17567 浏览量 回答数 8

回答

"三个字,不可能######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@DanceCoder : 没有这种数据库管理员,如果是系统里的管理员,倒是可以通过系统代码,实现管理员只能管理不能查看的逻辑。数据库本身的管理员不行,除非让数据库管理员都进不了数据库,那还管理啥。######回复 <a href=""http://my.oschina.net/visualgui823"" class=""referer"" target=""_blank"">@乌龟壳 : 面试官说可以执行增删改查,就是直接在控制台执行SQL语句的那种。######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@HankeBoom : 如果有背景就可能不一样,比如说的其实是所谓的数据库管理员之类的,就看看服务器状态那些,数据库都没权限进去######哈哈哈,面试官好坏。。。。。######你确认他不是在出脑筋急转弯? ######不知道,根据我仅有的面试经验,一般都是先问一些基础的问题。我也不知道他为什么问这么摸不着头脑的问题。难道是在考察我的解决问题能力?######<span style=""color:#444444;font-family:'Microsoft YaHei', Verdana, sans-serif, 宋体;font-size:14px;line-height:normal;background-color:#FFFFFF;""> 数据库管理员没有权限看数据库,感觉就像厨师不能进厨房一样。######面试官的意思是不要在管理员权限方面限制不同权限级别的管理员###### 在java程序是对用户名和密码进行了加密后存入数据库的,登录的时候时候再提取数据库的数据进行相反的解密过程,如果一致,才通过 根据你的描述,管理员A又可以管理服务器后台,又可以管理数据库,那只能说明管理员只能为一个(多了就权责不分了),当然最好的是 不要给A日志信息查看权限,要不然就他就可以做到天衣无缝。 以上是个人对数据安全性的理解 下面废话:1:不考虑数据库权限、不考虑加密、不考虑数据库类型,说明数据库安全性有问题。2:面试官的回答“登录修改用户密码和然后就可以登录了。” ,有点sb思维,我都看得到密码了,还用修改后台的密码,还要脱裤子放屁(多此一举) ######哈哈哈,面试官确实好坏###### 这种东西只有在登录的时候处理吧. 数据库都是持久性的东西, 不管如何加密. 只要修改成一个我知道的明文加密的数据不就行了? 所以,还是在登录的后台做处理. 比如加密的是根据用户输入的密码加上用户名之类的处理过的密码. 那么数据库管理员不知道后台的处理逻辑, 修改了数据库也无用. ######长知识了,谢谢######66666###### 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 ######就是性能堪忧######这个有点厉害啊###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 可是都说了不允许加密了,实在想不出不加密怎么办了######你需要了解MySQL的“视图”是干嘛的。。。。。。。######视图不是也可以执行改数据操作吗###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 引用来自“钛元素”的评论可是都说了不允许加密了,实在想不出不加密怎么办了 上面的加密只是为了去掉多个片段记录中用户名的相关性,让管理员无法通过搜索找出所有和这个用户名相关的记录项,不需要解密,只是一种变换算法。 "
montos 2020-06-04 16:18:47 0 浏览量 回答数 0

回答

"三个字,不可能######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@DanceCoder : 没有这种数据库管理员,如果是系统里的管理员,倒是可以通过系统代码,实现管理员只能管理不能查看的逻辑。数据库本身的管理员不行,除非让数据库管理员都进不了数据库,那还管理啥。######回复 <a href=""http://my.oschina.net/visualgui823"" class=""referer"" target=""_blank"">@乌龟壳 : 面试官说可以执行增删改查,就是直接在控制台执行SQL语句的那种。######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@HankeBoom : 如果有背景就可能不一样,比如说的其实是所谓的数据库管理员之类的,就看看服务器状态那些,数据库都没权限进去######哈哈哈,面试官好坏。。。。。######你确认他不是在出脑筋急转弯? ######不知道,根据我仅有的面试经验,一般都是先问一些基础的问题。我也不知道他为什么问这么摸不着头脑的问题。难道是在考察我的解决问题能力?######<span style=""color:#444444;font-family:'Microsoft YaHei', Verdana, sans-serif, 宋体;font-size:14px;line-height:normal;background-color:#FFFFFF;""> 数据库管理员没有权限看数据库,感觉就像厨师不能进厨房一样。######面试官的意思是不要在管理员权限方面限制不同权限级别的管理员###### 在java程序是对用户名和密码进行了加密后存入数据库的,登录的时候时候再提取数据库的数据进行相反的解密过程,如果一致,才通过 根据你的描述,管理员A又可以管理服务器后台,又可以管理数据库,那只能说明管理员只能为一个(多了就权责不分了),当然最好的是 不要给A日志信息查看权限,要不然就他就可以做到天衣无缝。 以上是个人对数据安全性的理解 下面废话:1:不考虑数据库权限、不考虑加密、不考虑数据库类型,说明数据库安全性有问题。2:面试官的回答“登录修改用户密码和然后就可以登录了。” ,有点sb思维,我都看得到密码了,还用修改后台的密码,还要脱裤子放屁(多此一举) ######哈哈哈,面试官确实好坏###### 这种东西只有在登录的时候处理吧. 数据库都是持久性的东西, 不管如何加密. 只要修改成一个我知道的明文加密的数据不就行了? 所以,还是在登录的后台做处理. 比如加密的是根据用户输入的密码加上用户名之类的处理过的密码. 那么数据库管理员不知道后台的处理逻辑, 修改了数据库也无用. ######长知识了,谢谢######66666###### 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 ######就是性能堪忧######这个有点厉害啊###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 可是都说了不允许加密了,实在想不出不加密怎么办了######你需要了解MySQL的“视图”是干嘛的。。。。。。。######视图不是也可以执行改数据操作吗###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 引用来自“钛元素”的评论可是都说了不允许加密了,实在想不出不加密怎么办了 上面的加密只是为了去掉多个片段记录中用户名的相关性,让管理员无法通过搜索找出所有和这个用户名相关的记录项,不需要解密,只是一种变换算法。 "
montos 2020-06-04 16:18:39 0 浏览量 回答数 0

回答

变形虫  amoeba-mysql.支持按照数据规则路由到不同的库、表。 不过好像不能完全满足你的需求,如果有对小库的CUD操作,大库中是不是要同步? ###### 引用来自“刘柳”的评论 变形虫  amoeba-mysql.支持按照数据规则路由到不同的库、表。 不过好像不能完全满足你的需求,如果有对小库的CUD操作,大库中是不是要同步? 不好意思我没有完整的表达应用场景。这个应用数据库表多且行数大,过亿条记录,且有的数据是实时生成,有的数据是根据所有数据统计分析生成,想找一个可行性高的平衡各方面因素的方案。目前的考虑是,不做从小库到大库的数据复制或同步,而只做定期从大库生成小库,再分别更新这两个分支的数据。这也不一定是最终方案。呵呵。。。 再问,看了一下mysql router,不支持按表名路由么?另外,amoeda可靠性怎么样啊?有哪些成熟应用呢?
kun坤 2020-06-06 15:59:54 0 浏览量 回答数 0

回答

我认为这里的人们所缺少的重要一点是,有了支持参数化查询的数据库,就不必担心“转义”。数据库引擎不会将绑定的变量组合到SQL语句中,然后再分析整个内容。绑定变量保持独立,并且永远不会解析为通用SQL语句。 这就是安全性和速度的来源。数据库引擎知道占位符仅包含数据,因此永远不会将其解析为完整的SQL语句。当您一次准备一条语句然后执行多次时,就会提速。典型示例是将多个记录插入到同一表中。在这种情况下,数据库引擎仅需要解析,优化等一次。 现在,数据库抽象库是一个难题。他们有时只是通过以适当的转义将绑定变量插入SQL语句中来伪造它。尽管如此,这总比自己动手做更好。来源:stack overflow
保持可爱mmm 2020-05-11 16:57:06 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档使用 数据传输服务 DTS 可以将本地 SQL Server 数据库实例的数据迁移到 RDS for SQL Server 实例。SQL Server 迁移支持增量数据同步功能,可以实现在本地应用不停服的情况下,平滑完成 SQL Server 数据库的迁移工作。 本小节简单介绍使用数据传输服务 DTS(以下简称 DTS) 进行 SQL Server->RDS for SQL Server 数据迁移的任务配置流程。 迁移类型对于 SQL Server->RDS for SQL Server 数据迁移,DTS 支持结构迁移、全量数据迁移及增量数据迁移,这个迁移类型的功能及限制如下: 结构迁移 DTS 将迁移对象的结构定义迁移到目标实例。目前 DTS 支持结构迁移的对象有:表、视图、表触发器、同义词、SQL 存储过程、SQL 函数、plan guid、自定义类型、rule、default。 全量数据迁移 全量迁移将 SQL Server 实例的存量数据全部迁移到目标 RDS 实例。如果您只进行全量数据迁移,那么迁移过程中本地 SQL Server 数据库实例新增的业务写入不会被同步到目标 RDS 实例。 如果您还选择了增量数据迁移,那么迁移过程中,本地 SQL Server 数据库实例的增量写入数据会被同步到目标 RDS 实例。 迁移限制 当前 SQL Server 结构迁移和全量数据迁移支持 SQL Server 2005,2008,2008 R2,2012 和 2016 版本,增量数据迁移支持 SQL Server 2008,2008 R2,2012 和 2014 版本。如果迁移的对象使用了对象名映射功能,则有一定几率导致依赖该对象的其他对象迁移失败。不支持 sql_variant 数据类型。结构迁移不支持 assemblies、库级存储过程、service broker、全文索引、全文目录、分布式 schema、分布式函数、CLR 标量函数、CLR 标值函数、内部表、聚合函数、系统的迁移。如果使用结构迁移 + 全量数据迁移 + 增量数据迁移,在结构迁移开始后,增量数据迁移开始前,请不要对迁移涉及的对象进行 DDL 操作,否则有一定几率会导致迁移失败。增量迁移的限制如下: 有限支持 DDL 语句同步,具体支持的 DDL 语句请参考 增量数据迁移过程中支持同步的 DDL 操作 章节。只支持含有聚簇索引,且聚簇索引为主键或者唯一键的表。不支持只更新大字段的 update 语句的同步。不支持含有计算列的表。一个增量迁移任务只支持一个数据库的迁移。如果同时有多个数据库需要进行增量数据迁移,那么需要创建多个迁移任务。 增量数据迁移过程中支持同步的增量数据迁移过程中支持同步的 DDL 操作 增量迁移过程中支持同步的 DDL 操作及其限制条件(在括号内说明)包括: CREATE TABLE (不支持函数,分区,默认值)ALTER TABLE … ADD COLUMN (不支持默认值)ALTER TABLE … DROP COLUMNALTER TABLE … ALTER COLUMN (不支持默认值)CREATE INDEX (不支持 index 属性)SP_RENAME table_nameSP_RENAME column_name 迁移权限要求当使用 DTS 进行 SQL Server 迁移时,不同迁移类型,对本地 SQL Server 数据库实例及目标 RDS for SQL Server 实例的迁移账号权限要求如下: 迁移类型 结构迁移 全量迁移 增量迁移 本地 SQLServer 数据库实例 select select sysadmin 目的 RDS for SQL Server 实例 读写权限 读写权限 读写权限 迁移流程数据传输服务在进行 SQL Server 上云迁移时,为了解决对象间的依赖,提高迁移成功率。 结构对象及数据的迁移顺序如下: 进行结构对象 表、视图、同义词、自定义类型、rule、default、plan guid 的迁移。全量数据迁移。进行结构对象 SQL 存储过程、SQL 函数、触发器、外键 的迁移。增量数据迁移。 如果任务没有选择增量数据迁移,那么当全量数据迁移完成后,任务列表中的迁移进度为:结构迁移100%,全量迁移100%,迁移状态为“迁移中”。此时迁移任务正在进行步骤(3)中的对象的迁移。此时,请勿手动结束任务,否则会造成迁移数据丢失。待迁移状态显示为“迁移完成”后,表示全量数据迁移任务已经完成,这时可以安全地手动结束任务。 迁移任务配置下面详细介绍使用 DTS 将本地的 SQL Server 迁移到 RDS for SQL Server 的任务配置流程。 RDS 实例数据库创建在数据迁移过程中,如果待迁移的数据库在目标 RDS for SQL Server 实例中不存在,那么 DTS 自动会创建同名的数据库。但是对于如下两种情况,您需要在配置迁移任务之前,手动创建数据库。 数据库名称不符合:RDS 定义规范 (由小写字母、数字、下划线、中划线组成,字母开头,字母或数字结尾,最长 64 个字符)。待迁移数据库,在本地 SQL Server 数据库实例跟目标 RDS for SQL Server 实例中名称不同。 对于这两种情况,您需要在配置迁移任务之前,先在 RDS 控制台完成 RDS for SQL Server 实例中数据库的创建。具体参考 RDS 数据库创建流程 RDS 使用手册。 迁移账号创建迁移任务配置,需要提供本地 SQL Server 数据库实例及目标 RDS 实例的迁移账号。迁移账号所需权限详见上文的迁移权限要求。 如果本地 SQL Server 数据库实例的迁移账号尚未创建,那么您可以参考 SQL Server User 创建,创建满足权限要求的迁移账号。 如果目标 RDS for SQL Server 实例迁移账号尚未创建,那么您可以参考 RDS 账号创建流程,创建对目标 RDS for SQL Server 实例有读写权限的迁移账号。 其他准备工作如果您需要进行不停机迁移,那么还需要设置本地 SQL Server 数据库实例日志格式为 full。 如果本地 SQL Server 数据库实例的日志格式不为 full,那么需要通过下面两个步骤设置: 在源数据库执行: alter database database_name set recovery_model_desc=’full’, 其中 database_name 为需要迁移的数据库名。为了保证开启完整日志生效,需要在源数据库进行一次日志备份,在源数据库执行:BACKUP LOG database_name to DISK=backup_place WITH init , 其中 database_name 为待迁移的数据库名,backup_place 为备份文件存储的地址。 迁移任务配置当数据库、迁移账号都创建完成后,就可以开始配置迁移任务了。下面详细介绍下具体的配置步骤。 进入数据传输 DTS 控制台,点击右上角的创建迁移任务,开始任务配置。本地 SQL Server 数据库实例及目标 RDS for SQL Server 实例连接信息配置。 在这个步骤中,主要配置迁移任务名称,迁移源实例及目标实例连接信息。其中: 任务名称 默认情况下,DTS 为每个任务自动生成一个任务名称。任务名称没有唯一性要求,您可以修改这个名称,为任务配置一个具有业务意义的名称,便于后续的任务识别。 源实例连接信息 实例类型:选择 有公网 IP 的自建数据库 数据库类型:选择 SQL Server主机名或IP地址:配置本地 SQL Serever 数据库实例的访问地址,这个地址必须为公网访问方式端口:SQL Server 实例监听端口数据库账号:SQL Server 数据库实例访问账号数据库密码:上面指定的 SQL Server 访问账号对应的数据库实例密码 目标 RDS 实例连接信息 实例类型:选择 RDS 实例RDS 实例 ID: 配置迁移的目标 RDS for SQL Server 实例的实例 ID。 DTS 支持经典网络和 VPC 网络的 RDS 实例数据库账号:RDS for SQL Server 实例的连接账号数据库密码:上面指定的数据库账号对应的数据库实例密码 迁移对象及迁移类型配置。 迁移类型 DTS 支持结构迁移、全量数据迁移、增量数据迁移。 如果需要进行不停机迁移,那么需要选择:结构迁移+全量数据迁移+增量数据迁移。 如果只进行全量迁移,那么需要选择:结构迁移+全量数据迁移。 迁移对象 迁移对象,需要选择您要迁移的对象。迁移对象选择的粒度可以为:库、表、列三个粒度。默认情况下,对象迁移到 RDS 实例后,对象名跟本地 SQL Server 数据库实例一致。如果您迁移的对象在源实例跟目标实例上名称不同,那么需要使用 DTS 提供的对象名映射功能,详细使用方式可以参考库表列映射。 当配置完迁移对象及迁移类型后,即进入任务启动前的预检查步骤 预检查。 在迁移任务正式启动之前,会先进行前置预检查,只有预检查通过后,才能成功启动迁移。 如果预检查失败,那么可以点击具体检查项后的按钮,查看具体的失败详情,并根据失败原因修复后,重新进行预检查。 启动迁移任务。 当预检查通过后,可以启动迁移任务,任务启动后,可以到任务列表中查看任务具体的迁移状态及进度。 增量数据迁移是个动态同步的过程,所以建议在增量迁移达到无延迟状态时,在目标数据库上进行业务验证,如果验证成功,那么可以停掉迁移任务,然后将业务切换到目标数据库。 至此,完成将本地 SQL Server 数据库实例到 RDS for SQL Server 实例的数据迁移任务配置。
2019-12-01 23:09:42 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档使用 数据传输服务 DTS 可以将本地 SQL Server 数据库实例的数据迁移到 RDS for SQL Server 实例。SQL Server 迁移支持增量数据同步功能,可以实现在本地应用不停服的情况下,平滑完成 SQL Server 数据库的迁移工作。 本小节简单介绍使用数据传输服务 DTS(以下简称 DTS) 进行 SQL Server->RDS for SQL Server 数据迁移的任务配置流程。 迁移类型对于 SQL Server->RDS for SQL Server 数据迁移,DTS 支持结构迁移、全量数据迁移及增量数据迁移,这个迁移类型的功能及限制如下: 结构迁移 DTS 将迁移对象的结构定义迁移到目标实例。目前 DTS 支持结构迁移的对象有:表、视图、表触发器、同义词、SQL 存储过程、SQL 函数、plan guid、自定义类型、rule、default。 全量数据迁移 全量迁移将 SQL Server 实例的存量数据全部迁移到目标 RDS 实例。如果您只进行全量数据迁移,那么迁移过程中本地 SQL Server 数据库实例新增的业务写入不会被同步到目标 RDS 实例。 如果您还选择了增量数据迁移,那么迁移过程中,本地 SQL Server 数据库实例的增量写入数据会被同步到目标 RDS 实例。 迁移限制 当前 SQL Server 结构迁移和全量数据迁移支持 SQL Server 2005,2008,2008 R2,2012 和 2016 版本,增量数据迁移支持 SQL Server 2008,2008 R2,2012 和 2014 版本。如果迁移的对象使用了对象名映射功能,则有一定几率导致依赖该对象的其他对象迁移失败。不支持 sql_variant 数据类型。结构迁移不支持 assemblies、库级存储过程、service broker、全文索引、全文目录、分布式 schema、分布式函数、CLR 标量函数、CLR 标值函数、内部表、聚合函数、系统的迁移。如果使用结构迁移 + 全量数据迁移 + 增量数据迁移,在结构迁移开始后,增量数据迁移开始前,请不要对迁移涉及的对象进行 DDL 操作,否则有一定几率会导致迁移失败。增量迁移的限制如下: 有限支持 DDL 语句同步,具体支持的 DDL 语句请参考 增量数据迁移过程中支持同步的 DDL 操作 章节。只支持含有聚簇索引,且聚簇索引为主键或者唯一键的表。不支持只更新大字段的 update 语句的同步。不支持含有计算列的表。一个增量迁移任务只支持一个数据库的迁移。如果同时有多个数据库需要进行增量数据迁移,那么需要创建多个迁移任务。 增量数据迁移过程中支持同步的增量数据迁移过程中支持同步的 DDL 操作 增量迁移过程中支持同步的 DDL 操作及其限制条件(在括号内说明)包括: CREATE TABLE (不支持函数,分区,默认值)ALTER TABLE … ADD COLUMN (不支持默认值)ALTER TABLE … DROP COLUMNALTER TABLE … ALTER COLUMN (不支持默认值)CREATE INDEX (不支持 index 属性)SP_RENAME table_nameSP_RENAME column_name 迁移权限要求当使用 DTS 进行 SQL Server 迁移时,不同迁移类型,对本地 SQL Server 数据库实例及目标 RDS for SQL Server 实例的迁移账号权限要求如下: 迁移类型 结构迁移 全量迁移 增量迁移 本地 SQLServer 数据库实例 select select sysadmin 目的 RDS for SQL Server 实例 读写权限 读写权限 读写权限 迁移流程数据传输服务在进行 SQL Server 上云迁移时,为了解决对象间的依赖,提高迁移成功率。 结构对象及数据的迁移顺序如下: 进行结构对象 表、视图、同义词、自定义类型、rule、default、plan guid 的迁移。全量数据迁移。进行结构对象 SQL 存储过程、SQL 函数、触发器、外键 的迁移。增量数据迁移。 如果任务没有选择增量数据迁移,那么当全量数据迁移完成后,任务列表中的迁移进度为:结构迁移100%,全量迁移100%,迁移状态为“迁移中”。此时迁移任务正在进行步骤(3)中的对象的迁移。此时,请勿手动结束任务,否则会造成迁移数据丢失。待迁移状态显示为“迁移完成”后,表示全量数据迁移任务已经完成,这时可以安全地手动结束任务。 迁移任务配置下面详细介绍使用 DTS 将本地的 SQL Server 迁移到 RDS for SQL Server 的任务配置流程。 RDS 实例数据库创建在数据迁移过程中,如果待迁移的数据库在目标 RDS for SQL Server 实例中不存在,那么 DTS 自动会创建同名的数据库。但是对于如下两种情况,您需要在配置迁移任务之前,手动创建数据库。 数据库名称不符合:RDS 定义规范 (由小写字母、数字、下划线、中划线组成,字母开头,字母或数字结尾,最长 64 个字符)。待迁移数据库,在本地 SQL Server 数据库实例跟目标 RDS for SQL Server 实例中名称不同。 对于这两种情况,您需要在配置迁移任务之前,先在 RDS 控制台完成 RDS for SQL Server 实例中数据库的创建。具体参考 RDS 数据库创建流程 RDS 使用手册。 迁移账号创建迁移任务配置,需要提供本地 SQL Server 数据库实例及目标 RDS 实例的迁移账号。迁移账号所需权限详见上文的迁移权限要求。 如果本地 SQL Server 数据库实例的迁移账号尚未创建,那么您可以参考 SQL Server User 创建,创建满足权限要求的迁移账号。 如果目标 RDS for SQL Server 实例迁移账号尚未创建,那么您可以参考 RDS 账号创建流程,创建对目标 RDS for SQL Server 实例有读写权限的迁移账号。 其他准备工作如果您需要进行不停机迁移,那么还需要设置本地 SQL Server 数据库实例日志格式为 full。 如果本地 SQL Server 数据库实例的日志格式不为 full,那么需要通过下面两个步骤设置: 在源数据库执行: alter database database_name set recovery_model_desc=’full’, 其中 database_name 为需要迁移的数据库名。为了保证开启完整日志生效,需要在源数据库进行一次日志备份,在源数据库执行:BACKUP LOG database_name to DISK=backup_place WITH init , 其中 database_name 为待迁移的数据库名,backup_place 为备份文件存储的地址。 迁移任务配置当数据库、迁移账号都创建完成后,就可以开始配置迁移任务了。下面详细介绍下具体的配置步骤。 进入数据传输 DTS 控制台,点击右上角的创建迁移任务,开始任务配置。本地 SQL Server 数据库实例及目标 RDS for SQL Server 实例连接信息配置。 在这个步骤中,主要配置迁移任务名称,迁移源实例及目标实例连接信息。其中: 任务名称 默认情况下,DTS 为每个任务自动生成一个任务名称。任务名称没有唯一性要求,您可以修改这个名称,为任务配置一个具有业务意义的名称,便于后续的任务识别。 源实例连接信息 实例类型:选择 有公网 IP 的自建数据库 数据库类型:选择 SQL Server主机名或IP地址:配置本地 SQL Serever 数据库实例的访问地址,这个地址必须为公网访问方式端口:SQL Server 实例监听端口数据库账号:SQL Server 数据库实例访问账号数据库密码:上面指定的 SQL Server 访问账号对应的数据库实例密码 目标 RDS 实例连接信息 实例类型:选择 RDS 实例RDS 实例 ID: 配置迁移的目标 RDS for SQL Server 实例的实例 ID。 DTS 支持经典网络和 VPC 网络的 RDS 实例数据库账号:RDS for SQL Server 实例的连接账号数据库密码:上面指定的数据库账号对应的数据库实例密码 迁移对象及迁移类型配置。 迁移类型 DTS 支持结构迁移、全量数据迁移、增量数据迁移。 如果需要进行不停机迁移,那么需要选择:结构迁移+全量数据迁移+增量数据迁移。 如果只进行全量迁移,那么需要选择:结构迁移+全量数据迁移。 迁移对象 迁移对象,需要选择您要迁移的对象。迁移对象选择的粒度可以为:库、表、列三个粒度。默认情况下,对象迁移到 RDS 实例后,对象名跟本地 SQL Server 数据库实例一致。如果您迁移的对象在源实例跟目标实例上名称不同,那么需要使用 DTS 提供的对象名映射功能,详细使用方式可以参考库表列映射。 当配置完迁移对象及迁移类型后,即进入任务启动前的预检查步骤 预检查。 在迁移任务正式启动之前,会先进行前置预检查,只有预检查通过后,才能成功启动迁移。 如果预检查失败,那么可以点击具体检查项后的按钮,查看具体的失败详情,并根据失败原因修复后,重新进行预检查。 启动迁移任务。 当预检查通过后,可以启动迁移任务,任务启动后,可以到任务列表中查看任务具体的迁移状态及进度。 增量数据迁移是个动态同步的过程,所以建议在增量迁移达到无延迟状态时,在目标数据库上进行业务验证,如果验证成功,那么可以停掉迁移任务,然后将业务切换到目标数据库。 至此,完成将本地 SQL Server 数据库实例到 RDS for SQL Server 实例的数据迁移任务配置。
2019-12-01 23:09:42 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档使用 数据传输服务 DTS 可以将本地 SQL Server 数据库实例的数据迁移到 RDS for SQL Server 实例。SQL Server 迁移支持增量数据同步功能,可以实现在本地应用不停服的情况下,平滑完成 SQL Server 数据库的迁移工作。 本小节简单介绍使用数据传输服务 DTS(以下简称 DTS) 进行 SQL Server->RDS for SQL Server 数据迁移的任务配置流程。 迁移类型对于 SQL Server->RDS for SQL Server 数据迁移,DTS 支持结构迁移、全量数据迁移及增量数据迁移,这个迁移类型的功能及限制如下: 结构迁移 DTS 将迁移对象的结构定义迁移到目标实例。目前 DTS 支持结构迁移的对象有:表、视图、表触发器、同义词、SQL 存储过程、SQL 函数、plan guid、自定义类型、rule、default。 全量数据迁移 全量迁移将 SQL Server 实例的存量数据全部迁移到目标 RDS 实例。如果您只进行全量数据迁移,那么迁移过程中本地 SQL Server 数据库实例新增的业务写入不会被同步到目标 RDS 实例。 如果您还选择了增量数据迁移,那么迁移过程中,本地 SQL Server 数据库实例的增量写入数据会被同步到目标 RDS 实例。 迁移限制 当前 SQL Server 结构迁移和全量数据迁移支持 SQL Server 2005,2008,2008 R2,2012 和 2016 版本,增量数据迁移支持 SQL Server 2008,2008 R2,2012 和 2014 版本。如果迁移的对象使用了对象名映射功能,则有一定几率导致依赖该对象的其他对象迁移失败。不支持 sql_variant 数据类型。结构迁移不支持 assemblies、库级存储过程、service broker、全文索引、全文目录、分布式 schema、分布式函数、CLR 标量函数、CLR 标值函数、内部表、聚合函数、系统的迁移。如果使用结构迁移 + 全量数据迁移 + 增量数据迁移,在结构迁移开始后,增量数据迁移开始前,请不要对迁移涉及的对象进行 DDL 操作,否则有一定几率会导致迁移失败。增量迁移的限制如下: 有限支持 DDL 语句同步,具体支持的 DDL 语句请参考 增量数据迁移过程中支持同步的 DDL 操作 章节。只支持含有聚簇索引,且聚簇索引为主键或者唯一键的表。不支持只更新大字段的 update 语句的同步。不支持含有计算列的表。一个增量迁移任务只支持一个数据库的迁移。如果同时有多个数据库需要进行增量数据迁移,那么需要创建多个迁移任务。 增量数据迁移过程中支持同步的增量数据迁移过程中支持同步的 DDL 操作 增量迁移过程中支持同步的 DDL 操作及其限制条件(在括号内说明)包括: CREATE TABLE (不支持函数,分区,默认值)ALTER TABLE … ADD COLUMN (不支持默认值)ALTER TABLE … DROP COLUMNALTER TABLE … ALTER COLUMN (不支持默认值)CREATE INDEX (不支持 index 属性)SP_RENAME table_nameSP_RENAME column_name 迁移权限要求当使用 DTS 进行 SQL Server 迁移时,不同迁移类型,对本地 SQL Server 数据库实例及目标 RDS for SQL Server 实例的迁移账号权限要求如下: 迁移类型 结构迁移 全量迁移 增量迁移 本地 SQLServer 数据库实例 select select sysadmin 目的 RDS for SQL Server 实例 读写权限 读写权限 读写权限 迁移流程数据传输服务在进行 SQL Server 上云迁移时,为了解决对象间的依赖,提高迁移成功率。 结构对象及数据的迁移顺序如下: 进行结构对象 表、视图、同义词、自定义类型、rule、default、plan guid 的迁移。全量数据迁移。进行结构对象 SQL 存储过程、SQL 函数、触发器、外键 的迁移。增量数据迁移。 如果任务没有选择增量数据迁移,那么当全量数据迁移完成后,任务列表中的迁移进度为:结构迁移100%,全量迁移100%,迁移状态为“迁移中”。此时迁移任务正在进行步骤(3)中的对象的迁移。此时,请勿手动结束任务,否则会造成迁移数据丢失。待迁移状态显示为“迁移完成”后,表示全量数据迁移任务已经完成,这时可以安全地手动结束任务。 迁移任务配置下面详细介绍使用 DTS 将本地的 SQL Server 迁移到 RDS for SQL Server 的任务配置流程。 RDS 实例数据库创建在数据迁移过程中,如果待迁移的数据库在目标 RDS for SQL Server 实例中不存在,那么 DTS 自动会创建同名的数据库。但是对于如下两种情况,您需要在配置迁移任务之前,手动创建数据库。 数据库名称不符合:RDS 定义规范 (由小写字母、数字、下划线、中划线组成,字母开头,字母或数字结尾,最长 64 个字符)。待迁移数据库,在本地 SQL Server 数据库实例跟目标 RDS for SQL Server 实例中名称不同。 对于这两种情况,您需要在配置迁移任务之前,先在 RDS 控制台完成 RDS for SQL Server 实例中数据库的创建。具体参考 RDS 数据库创建流程 RDS 使用手册。 迁移账号创建迁移任务配置,需要提供本地 SQL Server 数据库实例及目标 RDS 实例的迁移账号。迁移账号所需权限详见上文的迁移权限要求。 如果本地 SQL Server 数据库实例的迁移账号尚未创建,那么您可以参考 SQL Server User 创建,创建满足权限要求的迁移账号。 如果目标 RDS for SQL Server 实例迁移账号尚未创建,那么您可以参考 RDS 账号创建流程,创建对目标 RDS for SQL Server 实例有读写权限的迁移账号。 其他准备工作如果您需要进行不停机迁移,那么还需要设置本地 SQL Server 数据库实例日志格式为 full。 如果本地 SQL Server 数据库实例的日志格式不为 full,那么需要通过下面两个步骤设置: 在源数据库执行: alter database database_name set recovery_model_desc=’full’, 其中 database_name 为需要迁移的数据库名。为了保证开启完整日志生效,需要在源数据库进行一次日志备份,在源数据库执行:BACKUP LOG database_name to DISK=backup_place WITH init , 其中 database_name 为待迁移的数据库名,backup_place 为备份文件存储的地址。 迁移任务配置当数据库、迁移账号都创建完成后,就可以开始配置迁移任务了。下面详细介绍下具体的配置步骤。 进入数据传输 DTS 控制台,点击右上角的创建迁移任务,开始任务配置。本地 SQL Server 数据库实例及目标 RDS for SQL Server 实例连接信息配置。 在这个步骤中,主要配置迁移任务名称,迁移源实例及目标实例连接信息。其中: 任务名称 默认情况下,DTS 为每个任务自动生成一个任务名称。任务名称没有唯一性要求,您可以修改这个名称,为任务配置一个具有业务意义的名称,便于后续的任务识别。 源实例连接信息 实例类型:选择 有公网 IP 的自建数据库 数据库类型:选择 SQL Server主机名或IP地址:配置本地 SQL Serever 数据库实例的访问地址,这个地址必须为公网访问方式端口:SQL Server 实例监听端口数据库账号:SQL Server 数据库实例访问账号数据库密码:上面指定的 SQL Server 访问账号对应的数据库实例密码 目标 RDS 实例连接信息 实例类型:选择 RDS 实例RDS 实例 ID: 配置迁移的目标 RDS for SQL Server 实例的实例 ID。 DTS 支持经典网络和 VPC 网络的 RDS 实例数据库账号:RDS for SQL Server 实例的连接账号数据库密码:上面指定的数据库账号对应的数据库实例密码 迁移对象及迁移类型配置。 迁移类型 DTS 支持结构迁移、全量数据迁移、增量数据迁移。 如果需要进行不停机迁移,那么需要选择:结构迁移+全量数据迁移+增量数据迁移。 如果只进行全量迁移,那么需要选择:结构迁移+全量数据迁移。 迁移对象 迁移对象,需要选择您要迁移的对象。迁移对象选择的粒度可以为:库、表、列三个粒度。默认情况下,对象迁移到 RDS 实例后,对象名跟本地 SQL Server 数据库实例一致。如果您迁移的对象在源实例跟目标实例上名称不同,那么需要使用 DTS 提供的对象名映射功能,详细使用方式可以参考库表列映射。 当配置完迁移对象及迁移类型后,即进入任务启动前的预检查步骤 预检查。 在迁移任务正式启动之前,会先进行前置预检查,只有预检查通过后,才能成功启动迁移。 如果预检查失败,那么可以点击具体检查项后的按钮,查看具体的失败详情,并根据失败原因修复后,重新进行预检查。 启动迁移任务。 当预检查通过后,可以启动迁移任务,任务启动后,可以到任务列表中查看任务具体的迁移状态及进度。 增量数据迁移是个动态同步的过程,所以建议在增量迁移达到无延迟状态时,在目标数据库上进行业务验证,如果验证成功,那么可以停掉迁移任务,然后将业务切换到目标数据库。 至此,完成将本地 SQL Server 数据库实例到 RDS for SQL Server 实例的数据迁移任务配置。
2019-12-01 23:09:43 0 浏览量 回答数 0

回答

1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后,对我们设计录入界面大有好处。 〖例1〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 一般而言,一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。 因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。 3. 基本表的性质 基本表与中间表、临时表不同,因为它具有如下四个特性: 原子性。基本表中的字段是不可再分解的。原始性。基本表中的记录是原始数据(基础数据)的记录。演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。 4. 范式标准 基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。〖例2〗:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。在Rose 2002中,规定列有两种类型:数据列和计算列。“金额”这样的列被称为“计算列”,而“单价”和“数量”这样的列被称为“数据列”。640?wx_fmt=png 表1 商品表的表结构 5. 通俗地理解三个范式 通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解): 第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解 第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性; 第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。 没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。 6. 要善于识别与正确处理多对多的关系 若两个实体之间存在多对多的关系,则应消除这种关系。消除的办法是,在两者之间增加第三个实体。这样,原来一个多对多的关系,现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。 这里的第三个实体,实质上是一个较复杂的关系,它对应一张基本表。一般来讲,数据库设计工具不能识别多对多的关系,但能处理多对多的关系。 〖例3〗:在“图书馆信息系统”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的关系,是一个典型的多对多关系:一本图书在不同时间可以被多个读者借阅,一个读者又可以借多本图书。为此,要在二者之间增加第三个实体,该实体取名为“借还书”,它的属性为:借还时间、借还标志(0表示借书,1表示还书),另外,它还应该有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”连接。 7. 主键PK的取值方法 PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引占用空间大,而且速度也慢。 8. 正确认识数据冗余 主键与外键在多表中的重复出现, 不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。〖例4〗:商品中的“单价、数量、金额”三个字段,“金额”就是由“单价”乘以“数量”派生出来的,它就是冗余,而且是一种高级冗余。冗余的目的是为了提高处理速度。 只有低级冗余才会增加数据的不一致性,因为同一数据,可能从不同时间、地点、角色上多次录入。因此,我们提倡高级冗余(派生性冗余),反对低级冗余(重复性冗余)。 9. E--R图没有标准答案 信息系统的E--R图没有标准答案,因为它的设计与画法不是惟一的,只要它覆盖了系统需求的业务范围和功能内容,就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案,并不意味着可以随意设计。好的E—R图的标准是:结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。 10. 视图技术在数据库设计中很有用 与基本表、代码表、中间表不同,视图是一种虚表,它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口,是基表数据综合的一种形式, 是数据处理的一种方法,是用户数据保密的一种手段。 为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。 对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统,视图的作用更加重要。这些系统的基本表完成物理设计之后,立即在基本表上建立第一层视图,这层视图的个数和结构,与基本表的个数和结构是完全相同。并且规定,所有的程序员,一律只准在视图上操作。 只有数据库管理员,带着多个人员共同掌握的“安全钥匙”,才能直接在基本表上操作。请读者想想:这是为什么? 11. 中间表、报表和临时表 中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的,存放临时记录,为个人所用。基表和中间表由DBA维护,临时表由程序员自己用程序自动维护。 12. 完整性约束表现在三个方面 域的完整性:用Check来实现约束,在数据库设计工具中,对字段的取值范围进行定义时,有一个Check按钮,通过它定义字段的值城。 参照完整性:用PK、FK、表级触发器来实现。用户定义完整性:它是一些业务规则,用存储过程和触发器来实现。 13. 防止数据库设计打补丁的方法是“三少原则” 1、一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的E--R图少而精,去掉了重复的多余的实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计; 2、一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间; 3、一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简单,有的人就是不习惯、不采纳、不执行。 数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功能,一百个实体(共一千个属性) 的E--R图,肯定比二百个实体(共二千个属性)的E--R图,要好得多。 提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。 集成的程度越高,数据共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章,不计其数,导致企事业单位的信息系统无法维护而瘫痪。 “三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。 14. 提高数据库运行效率的办法 在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是:在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方式用C++语言计算处理完成之后,最后才入库追加到表中去。这是电信计费系统设计的经验。 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键PK的某个值为界线,将该表的记录水平分割为两个表。若发现某个表的字段太多,例如超过八十个,则垂直分割该表,将原来的一个表分解为两个表。 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。 总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三个层次上同时下功夫。
茶什i 2019-12-27 15:54:46 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT