数据库考试笔记

对称算法共持一个密钥，非对称算法各持一个密钥。

MD5 DES 3DES RSA加密算法按时间复杂度排序是依次增加的，因为MD5采用的是散列，3DES是DES将按矩阵形式计算3遍

MD5是message-digest algorithm 5（信息-摘要算法）的缩写，被广泛用于加密和解密技术上，它可以说是文件的"数字指纹"。任何一个文件，无论是可执行程序、图像文件、临时文件或者其他任何类型的文件，也不管它体积多大，都有且只有一个独一无二的MD5信息值，并且如果这个文件被修改过，它的MD5值也将随之改变。因此，我们可以通过对比同一文件的MD5值，来校验这个文件是否被"篡改"过。

     对称加密算法是应用较早的加密算法，技术成熟。在对称加密算法中，数据发信方将明文（原始数据）和加密密钥一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。此外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量成几何级数增长，密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。对称加密算法的安全性取决于加密密钥的保存情况，但要求企业中每一个持有密钥的人都保守秘密是不可能的，他们通常会有意无意的把密钥泄漏出去——如果一个用户使用的密钥被入侵者所获得，入侵者便可以读取该用户密钥加密的所有文档，如果整个企业共用一个加密密钥，那整个企业文档的保密性便无从谈起。

      .Net中支持的对称加密算法主要有:DES,RC2,Rijndael,TripleDES。

      非对称加密算法使用两把完全不同但又是完全匹配的一对钥匙—公钥和私钥。在使用非对称加密算法加密文件时，只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。加密明文时采用公钥加密，解密密文时使用私钥才能完成，而且发信方（加密者）知道收信方的公钥，只有收信方（解密者）才是唯一知道自己私钥的人。非对称加密算法的基本原理是，如果发信方想发送只有收信方才能解读的加密信息，发信方必须首先知道收信方的公钥，然后利用收信方的公钥来加密原文；收信方收到加密密文后，使用自己的私钥才能解密密文。显然，采用非对称加密算法，收发信双方在通信之前，收信方必须将自己早已随机生成的公钥送给发信方，而自己保留私钥。由于非对称算法拥有两个密钥，因而特别适用于分布式系统中的数据加密。如果企业中有n个用户，企业需要生成n对密钥，并分发n个公钥。由于公钥是可以公开的，用户只要保管好自己的私钥即可，因此加密密钥的分发将变得十分简单。同时，由于每个用户的私钥是唯一的，其他用户除了可以可以通过信息发送者的公钥来验证信息的来源是否真实，还可以确保发送者无法否认曾发送过该信息。非对称加密的缺点是加解密速度要远远慢于对称加密，在某些极端情况下，甚至能比非对称加密慢上1000倍。广泛应用的不对称加密算法有RSA算法和美国国家标准局提出的DSA。

      .Net中支持的非对称加密算法主要有:DSA,RSA。

      Hash算法(哈希值) 
Hash算法特别的地方在于它是一种单向算法，用户可以通过Hash算法对目标信息生成一段特定长度的唯一的Hash值，却不能通过这个Hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。 
      .Net中支持的Hash算法主要有:HMACSHA1,MACTripleDES,MD5,SHA1,SHA256,SHA384,SHA512。

问：对称加密（encryption）和非对称加密算法之间有什么区别，尤其是涉及到加密、签名和哈希（hash）时？

答：在谈到加密的时候，最新的不一定是最好的。你应该选择那种合适的、已经被大量公开分析和测试过的加密算法，因为在密码学领域是没有机会去尝试一个新算法的。让我们来看看一些已经被广泛应用的算法。

对绝大多数人来说，加密就是将明文转换为密文的过程，用密钥（key）或者密码（secret）来对内容进行加密和解密。这就是对称加密，相对于其他类型的加密方法（如，非对称加密），它速度更快。在对称密匙加密中，应用最为广泛的是AES（高级加密标准），它包含三个加密模块：AES-128、AES-192和AES-256，其中任何一种都足以有效保护政府的机密（SECRET）信息，最高机密（TOP SECRET）采用的是192位或者256位长度的密钥。

对称密匙加密最大的缺点是：所有参与的部门在他们解密前必须交换他们用于加密的密钥。这要求必须安全地发布和管理大量密钥数据，也意味着大多数的密码服务还需要其他类型的加密算法。例如为了具备不可抵赖性（non-repudiation），Secure MIME（S/MIME）采用了一种非对称算法（公钥/私钥算法），还使用了一种对称算法来对隐私和数据进行有效地保护。

非对称加密算法采用两个相互依赖的密钥：一个进行加密，另一个进行解密。这种相互依赖的关系提供了一些不同特性，其中最重要的也许是数字签名，它可以确保一条信息被某个特定的实体或者远程授权的系统或者用户创建。RSA（Rivest,Shamir and Adleman）非对称加密算法被广泛地应用于电子商务协议（如SSL），考虑到RSA提供了充分长的密钥并利用了最新的实现方式，它被认为是安全的。由于RSA比对称密码要慢很多，所以典型的做法是对数据使用对称算法进行加密，然后再使用RSA算法对较短的对称密匙进行加密。这使得解密数据所需的密钥可以安全地随对称加密数据一起传到另一方。

在某种程度上，一个加密哈希的功能与其他加密算法有所不同。例如，它可以返回一个数据、一个文件或者信息的值。一个好的哈希算法能够避免针对某个哈希值产生一个初始输入，并禁止通过哈希值逆推出初始输入。MD5和SHA-1曾是被广泛应用的哈希算法，但现在它们的加密强度都不够了，已被SHA-244、SHA-256、SHA-384或SHA-512所代替（这些算法有时会被统一看成是SHA-2算法）。微软甚至表示，早在2005年它就禁止开发者在任何场合都使用DES、MD4和MD5，在某些情况下甚至禁止使用SHA-1加密算法。虽然针对SHA-2的各个版本还未出现任何攻击报告，但它们在算法上和SHA-1很相似，所以SHA-3在未来几年将会以一种和AES相似的方式被选择成为新的哈希方式。正如你所能看到的，密码学领域总是在不断的变化，并始终和最新的技术发展保持一致，你需要做的是紧跟美国国家标准与技术研究院（National Institute of Standards and Technology）这类机构所发出的消息和建议。

数据库镜像

目录

简介

定义

作用

注意事项

编辑本段简介

为了避免 介质故障影响数据库的可用性，许多DBMS还可以提供了数据库镜像（mirror）和复制功能，它不同于数据转储，一般由DBMS按 DBA的要求自动完成。

编辑本段定义

数据库镜像是 DBMS根据 DBA的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上，每当主数据库更新时，DBMS会自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。 ^[1]

编辑本段作用

当出现介质故障时，可由镜像磁盘继续提供数据库的可用性，同时DBMS自动利用镜像磁盘进行数据库的修复，不需要关闭系统和重装数据库副本。

没有出现故障时，数据库镜像还可以用于并发操作。即当一个用户对数据库加排他锁修改数据时，其他用户可以读镜像数据库，而不必等待该用户释放锁。

编辑本段注意事项

数据库镜像是通过复制数据实现的，频繁地复制自然会降低系统运行效率，因此在实际应用中用户往往只选择对关键数据镜像，如对日志文件镜像，而不是对整个数据库进行镜像。

数据库的死锁问题在设计期就可以避免

前几天偶尔与一位数据库工程师谈起数据库的死锁(deadlock)问题。根据以往的经验，我一直认为： 

　　1.MSSQL、DB2、Oracle之类的现代DBMS或者中间件可以帮助我们自动解决绝大部分死锁，其余一部分难以处理的死锁则由DBA在数据库控制端手工处理。就应用程序而言，不需要在源代码级过多考虑地考虑死锁问题。 

　　2.死锁的发生对系统的性能和吞吐量有着明显的影响，但只要存在针对共享数据资源的大规模并发访问的情况，那么死锁是不可避免的。 

　　理论上，预防死锁的最好的途径是：给每一个transaction设定一个优先级，同时确保较低优先级的事务不必等待较高优先级事务释放共享资源，反过来，也确保较高优先级的事务能够立刻取得相应的资源。如果开发人员无法判别事务的优先级，那么可以考虑在每个事务开始时赋予它一个的时间戳，依据时间戳的先后来判定事务的优先级，这类似于FIFO队列。在这方面，现代DBMS都提供了相应的语言支持。但是，假设由于网络故障而导致高优先级的事务无法commit或者rollback，那么是否其他低级别事务便要一直等待或者被抛弃？或者一个事务中的update操作施加了多个表级锁，并且占用了大量时间，那么即便这种事务从逻辑上并不合理，是否也要保持它的高优先级？ 

　　针对稀缺资源的竞争在任何场合都是正常的，死锁出现的因果关系给予我一个提示，就是不能盲目地依赖DBMS和DBA在死锁发生后再去解决死锁问题，那样必然已经对用户体验造成了消极影响。开发人员在设计过程中，需要更多地研判可能的并发访问问题。这些问题可能包括： 

　　1.尽可能缩短事务。在同一DB中并发执行多个需要长时间运行的事务时，发生死锁的概率较大。事务运行时间越长，其持有exclusive锁或update锁的时间便越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。同时，涉及多个表的查询更新操作，若比较耗时，尽量不要放在一个事务内处理，能分割便分割。若不能分割，便尽可能使之在业务量较小的时间(例如子夜或者午餐时间)执行。 

　　2.尽可能按同一顺序访问数据对象。如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。 

　　3.避免编写包含用户交互的事务。因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，若用户不能及时反馈，则此事务将挂起。因而将严重降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。 

　　4.使用低隔离级别。确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。 

　　5.考虑体系结构的优化与代码重构，提高系统整体的运行效率。例如尽可能不要采用类似EJB的效率低下的计算模型，或者将复杂的业务置于编译存储过程中执行。 

　　6.通过程序控制事务提交的时机。如果一次检索出了10万条记录但只更改了其中的100条，就可以通过代码来执行100个update。或是用分段提交，即所有的修改使用多个事务进行提交，但这样会使事务不完整，应酌情使用。 

　　7.将经常更新的数据库和查询数据库分开。定期将不改变的数据导入查询数据库中，这样查询和更新就可以分开进行，而降低死锁机率。 

　　8.在进行数据库模式设计时，注意外键引用的完整性，并对外键加索引。如果更新了父表的主键，由于外键上没有索引，所以子表会被锁定；如果删除了父表中的一行，整个子表也会被锁定。 

　　网上有很多关于死锁问题的讨论，在理论方面，R.Ramakrishnan的《Database management systems》也有非常精辟的阐述。就实际开发而言，不同的数据库环境有着不同的处理方法，不同的体系架构也会导致不同的结果，这些开发人员需要更多地考虑的。