数据库原理及应用基础的常见类型题

1B 2C 3B 4C 5D 6C 7C 8D 9C 10A

11A 12A 13A - 不知道14。乙evogue2006 - 10 - 24 11点47分01秒1516A 17B 18A 19D 20C

试述事务的概念和事务的四个特性。

A：

事务是一个用户定义的数据库 *** 作序列，这些 *** 作要么全部做或不做的整体，是一个不可分割的工作单元。

事务有四个特点：原子性（原子性），一致性（一致性），隔离（隔离）和持久性（Durability）。这四个特点也被称为ACID属性。

原子性：事务数据库的逻辑工作单元，该交易包括所有的 *** 作，无论是做还是不做。

一致性：事务执行的结果必须更改数据库从一个一致状态转换到另一个一致的状态。

隔离：一个事务的执行不能被其他事务的干扰。一个事务内的 *** 作和使用其他并发事务的数据分离出来，并发执行的个别交易不能互相干扰。

持续性：持续性的，也被称为永久（持久性），指的到交易提交其数据存储在数据库中的变化应该是永久性的。接下来的 *** 作或故障不应该有任何影响其执行结果。

2。为什么事务非正常时间的推移，会影响数据库中数据的正确性，举了一个例子。

A：

事务的执行结果必须更改数据库从一个一致状态转换到另一个一致状态。如果出现故障的数据库系统的 *** 作，一些尚未完成的交易被迫中断，这些未完成的交易的一部分已被写入到物理数据库对数据库所做的更改，然后在数据库中不正确的状态，或者是不一致的状态。

如一个工厂的库存管理系统，它是必要的量Q的某些部分从仓库1仓库2个存储。

你可以定义一个事务T，T包括两个 *** 作; Q1 = Q1-Q，Q2 = Q2 + Q T改变的终止，只有当第一个 *** 作，数据库是不一致Q库存没有理由。

3。数据库中为什么要有恢复子系统？它的功能是什么？

A：

是不可避免的，因为计算机系统的硬件故障，软件错误， *** 作错误和恶意破坏所造成的这些故障从正在运行的事务中发生非正常中断，影响数据库中的数据正确性，而破坏了数据库中，因此，在数据库中的数据的全部或部分损失，因此必须有一个恢复子系统。功能

恢复子系统：数据库从错误状态恢复到一个已知的良好状态（也被称为一致的状态或完整状态）。

4。在数据库中可能出现的故障运行几类？什么故障影响正常执行的交易吗？什么故障破坏数据库中的数据？

A：数据库系统的各种可能发生的故障大致可分为如下几类：

（1）内部交易失败;

（2）系统故障; />（3）介质故障;

（4）计算机病毒。的

交易失败，系统故障和介质故障影响事务的正常执行;介质故障和计算机病毒破坏的数据

库。

5。根据回收技术？

A：

数据转储和登录日志文件是数据库恢复的基本技术。

当一个故障在系统运行过程中，转储数据库的日志文件，你可以将数据库恢复到一致状态，在发生故障之前的备份副本。

6。数据库的转储的意义是什么？各种数据转储方法的比较。

答案：

数据转储是基本的技术，在恢复的数据库。所谓的转储数据库DBA定期复制到磁带或其他磁盘保存。可以重新加载数据库破坏的数据库的备份副本恢复时的状态转储。

静态转储：转储系统 *** 作运行的事务。静态转储，但必须等待用户交易结束之前运行。同样，新的事务必须等待执行转储结束。显然，这将减少数据库的可用性。

动态转储：转储期间允许数据库访问或。动态的转储可以克服静态转储的缺点，它并不需要等待正在运行的用户交易的结束，也不会影响新事务的 *** 作。然而，备份的数据副本结束时的转储和不能保证正确和有效的。 ，因为转储运行在交易过程中可能会一些数据，备份的数据副本是不符合版本的数据库。

为此，我们必须活动期间注册使用dump transaction数据库，以创建一个日志文件（日志文件）。在这样的日志文件的备份副本可以得到正确的数据库状态的时刻。

转储海量转储和增量转储可以分为两种方式。

大规模倾倒每一个转储所有数据库。增量转储每次更新只转储上次转储数据。从恢复的角度来看，大量的转储的备份副本恢复一般更容易。如果该数据库，事务处理，是非常频繁，增量转储方式更实用，更有效。

7。日志文件？为什么要建立一个日志文件？

答案：

（1）日志文件是用来记录交易文件对数据库的更新 *** 作。

（2）建立的日志文件的目的：交易故障恢复系统故障恢复;协助媒体恢复的备份副本。

登记日志文件为什么要写入日志文件后，写入到数据库？

A：

的数据写入到数据库中，两种不同的 *** 作，这个后的日志记录被写入到日志文件中。这两个 *** 作之间可能发生了故障，即这两个写 *** 作只完成了。

先写一个数据库，而不是变化的运行记录中，小数点后不能被恢复这一。如果你写的日志，但没有数据库，恢复执行UNDO *** 作，不影响数据库的正确性。所以一定要确保你写的日志文件，日志记录写入到日志文件中，然后写入到数据库的变化。

9，测试是针对不同的故障恢复策略和方法。 （也就是说，如何进行交易系统故障恢复故障恢复介质恢复？）

A：

交易故障恢复：

事务故障的恢复是自动完成的DBMS ，是对用户透明。

DBMS执行恢复步骤：

（1）反向扫描文件日志（即从最后一次扫描日志文件），则该事务更新 *** 作。

（2）事务的更新 *** 作执行逆 *** 作。关于日志记录更新前值吗？写入到数据库中。

（3）反向扫描日志文件，做同样的。

（4）？下去，直到你读的开始标记本次交易，交易失败恢复完整。

A：

系统故障恢复：

系统出现故障可能会导致数据库处于不一致的状态：

首先，没有完成的交易数据库的更新可能已被写入到数据库中;

已提交的交易数据库的更新可能还留在缓冲区中，并没有写入到数据库。

恢复 *** 作（UNDO）的未竟事业出现故障，重做（REDO）已完成的交易。

恢复步骤：

（1）正向扫描日志文件，以确定该交易已提交在故障发生前队列中（REDO队列的）和未完成的事务队列（UNDO队列）。

（2）UNDO处理队列中的个别交易的。

UNDO处理方法是反向扫描日志文件，更新 *** 作执行相反的 *** 作，每一个UNDO事务迫在眉睫的“价值”（前映像）记录写入到数据库中，然后再更新。

（3）治疗重做重做队列事务。

REDO处理方法：正向扫描日志文件，每个REDO事务重新执行 *** 作的日志文件登记。即将推出的日志记录写入到数据库中的更新值“（后映像）。

分辨率：

步骤（1）如何确定的REDO队列和UNDO队列，请考虑一下吧。 BR />的算法如下：

1）创建两个事务队列：

·UNDO-LIST：需要执行undo *** 作的事务集;

·REDO-LIST：需要执行重做 *** 作事务集;

事务队列最初是空的。

）从日志文件头，正向扫描日志文件

是否有新的开始（遇到BEGIN TRANSACTION）交易钛，钛暂时放入UNDO-LIST队列;

·如果提交的事务（遇到结束事务）TJ TJ从队列undo-list中的REDO-LIST队列;

直到最后的日志文件A：

介质故障恢复：

介质故障是最严重的故障。

恢复方法是重装数据库，然后重做已完成交易的过程是：

（1 ）DBA装入最新的数据库备份（从故障时间最近的转储副本），将数据库恢复到一致的状态转储。

（2）DBA的日志文件的副本加载转储结束时间

（3）DBA启动系统恢复命令来完成还原的DBMS的功能，重做已完成的交易。

解析

1）我们假设静态转储的步骤（1）安装数据库的备份副本。

2）如果您使用的是静态和动态转储步骤（1）将数据库的备份副本是不够的，需要同时加载的副本日志文件的转储开始治疗后的时间，以获得正确的数据库的备份副本。

3）（2）步算法来重做已完成的交易：

正向扫描日志文件，以找出识别在故障发生之前提交的交易中，计入的重量队列

B。再次向前扫描日志文件，重做重做队列中的所有交易。即将推出的日志记录写入到数据库中的更新值。

>

10。检查点恢复技术的优势是什么？

A：

测井技术进行数据库恢复，恢复子系统必须搜索日志，以确定哪些事务需要重做，哪些事务需要。一般来说，你需要检查所有的记录。这样做有两个问题：

首先，搜索整个日志将花费大量的时间。

REDO处理的事务实际上写的更新 *** 作数据库恢复子系统又执行这些 *** 作，浪费了大量的时间。

检查点技术，以解决这些问题。

11。师叔检查点的恢复步骤。

①从启动文件的最后一个检查点记录在日志文件中的地址找到最后一个检查点记录在日志文件中找到的地址。

②检查站的检查点记录的建立时间列表中的所有运行的事务ACTIVE-LIST。

创建两个事务队列：

·UNDO-LIST：需要执行undo *** 作的事务集;

·REDO-LIST：集交易需要执行恢复 *** 作;

ACTIVE-LIST暂时到UNDO-LIST队列，REDO队列暂时空。

③从检查点开始正向扫描日志文件

任何新的起点事务钛undo-list中的Ti暂时放置在队列中;

·如果提交事务TJ，TJ移动从UNDO-LIST队列，REDO-LIST队列，直到最后的日志文件;

>④UNDO *** 作执行undo-list中的每一笔交易REDO-LIST中的每个事务执行REDO *** 作。

12。数据库镜像？使用？

答案：

数据库镜像是根据对DBA的要求，自动复制到另一个磁盘上的关键数据在整个数据库或部分。每当主数据库更新时，DBMS自动复制更新后的数据，在过去，DBMS自动保证镜像的一致性

使用数据库镜像的数据和主数据。：

一个用于数据库恢复。当介质故障的镜像磁盘继续提供使用的数据库管理系统自动镜像磁盘数据恢复的数据库，并且不需要关闭系统并重新安装该数据库的副本。

二是要提高无故障，当用户的数据加排他锁来其他用户可以读取的数据的数据库的可用性。镜像数据库，无需等待用户释放该锁。

我们首先来看一下什么是数据镜像： 现在几乎所有的应用系统都是基于数据库的，那么数据库的负荷是比较大的，在一天24小时中，任何时间都有可能会有数据要保存到数据库，或是从数据库中读出数据。任意时刻都会有用户连接到我们的数据库服务器上，几十，几百甚至成千上万个用户来连接使用我们的数据库，那么不论是计划内的宕机还是计划外的故障都会造成一定的损失。给我们的用户或是企业带很大的损失，特别是随着数据时代的到来，用户对数据的使用提出了更高的要求，那么作为一个DBA，就要想怎么做才能将这个损失减少到最低，正是因为基于这种需求，数据库镜像技术出现了！SQL SERVER2005中首次提出了数据库镜像概念。特点： 基于软件的高可用性解决方案 那是完全基于软件的高可用性解决方案。不需要增加硬件成本，也就是低硬件成本 快速的故障转移恢复， 最主要的一个亮点，就是快速的故障转移恢复。3秒（对于用户或是DBA是特别有吸引力的） 数据量大的情况一般10秒 在这个数据库镜像技术中有一个数据库服务器我们称为主数据库。它负责用户的连接和数据的处理。还有一个是从服务器，确切来说，这里应该叫镜像服务器，上面也有一个数据库，叫镜像数据库，这个数据库用于存放我们主数据库的一个热备份。也就是说它虽然不连接用户机，但是它对于主服务器上的数据更改呀，变化呀，都能做一个热备份，也就是说如果用户更新了主数据库中的内容，那么主数据库会根据镜像技术将更新传送给镜像服务器，这样就能保证主服务器和从服务器之间的数据是一致的，那么假如说由于某种原因，我们的主服务器或是主数据库不可用了，例如，网络中断，系统故障等等，那么客户端会重新定向到镜像服务器，那么客户端仍然能读取数据，写入数据，他感觉不到主数据库服务已经宕机了。所以采用数据库镜像技术以后，对于用户来说这个可用性就增强了，而且对于故障恢复时间也缩短了。那么客户仍然可以向镜像数据库上写数据。读数据，更新相关的事务，这是我们应用数据库镜像的一个过程。 想实现这个过程，必须要涉及到这么几个角色： 数据库镜像中的服务器角色：这几个角色刚才通过图形介绍了一点，那么在2005中有三种服务器角色，分别是 主体服务器：承载主体数据库 接受用户连接和事务处理请求 也就是说主体服务器正常的情况下就是主体服务器来提供服务 镜像服务器：承载镜像数据库 作为主体数据库的执备份 所谓热备份是说，主体数据库上的变化会立即反应硬驱镜像数据库上。 仅在故障转移后接受用户连接，处理事务请求 见证服务器：监视服务器状态和连接性，实现自动故障转移 也就是说见证服务器会时刻监视两个服务器的状态和连接性，当主体服务器发生宕机或者不可用以后，见证服务器会立即启用故障转移，将镜像服务器切换为主体服务器。继续为用户提供服务器 这是数据库镜像中的三个服务器角色，但是要注意一下就是这三个角色不是固定下来的，是可以变化的： 主体数据库和镜像数据库互为伙伴： 主体和镜像是可以相互转换的 故障转移后伙伴角色发生变化 当主体服务器正常的情况下，用户所有的连接及数据的更新都是直接送到主体服务器的，只不过是主体服务器再将数据备份到镜像服务器上，但是主体服务器不可用时，此时角色就发生了改变。镜像服务器就变成了主体服务器。那么如果原来的主体服务器恢复正常了，那么怎么办，它就会成为镜像服务器。所以它们的角色就彻底变化了。那如果这个服务器又不可用了。那么又是一个转换的过程。 那大家可能又要问一个问题就是这三个角色怎么知道到底哪一个可用，哪一个不可用： 各个服务器实例通过PING交换消息相互监视。与DOS命令的PING原理差不多，但是功能比DOS下的PING要强大的多，DOS下的PING只是检查网络的连通性，而此处的PING即要监视网络的连通性，这是第一步，还要监视数据库服务器实例的运行情况，服务器是否是正常的，还有就是这个服务器上的数据库是否正常。 总结一下数据库镜像工作过程： 正常情况下，配置好数据库镜像以后，用户只能连接主体数据库，但此时镜像数据库是不可用的。用户连上去也没有用。用户只能使用主体服务器时，主体服务器会将数据一方面写到自己的数据库中，另一方面通过事务日志的方式传给镜像服务器，写到镜像服务器的数据库，此时主体服务器会进入一个等待状态。等待镜像服务器的确认，也就是当镜像服务器的数据成功写入到镜像数据库以后会发一个消息给主体数据库，说我现在已经完成了数据的更新了也就是在镜像服务器上执行了一个REDO的过程。这是一个确认。当主体服务器收到这个确认以后会给客户端一个回应，说刚才的那个数据更新的 *** 作已经完成了 那么为什么能实现一个快速恢复机制，这主要和2005中的一个机制是分不开的 但SQL 2005不是没有必要等到回滚结束只要在REDO之后就可以使用了，至于UNDO的 *** 作，在用户使用的过程中你再继续UNDO，所以当主体服务器发生数据更新了，镜像服务器会以最短的时候来时间更新，以至于如果主体数据发生故障了，镜像服务器右以在最短的时间内接替主服务器进行工作。 下面来介绍一下数据库镜像中的三种 *** 作模式： 高可用性：最常用的。 高级别保护 高性能 下面咱们分别来看一下这三种模式，当然最主要的就是高可用性，这是使用比较广的一个模式 高可用性模式： 服务器角色： 主体服务器 镜像服务器 见证服务器 应用场景： 要求高可用性的场合 如股票交易 证券交易 银行等。 要求实现自动故障转移 确保数据的完整： 要求只要是用户提交到服务器上的数据，那怕说数据刚提交上主体服务器就发生故障了，也能保证数据不会丢失。故障转移之后的数据是不会丢失，从而保证数据库的完整性 高级别保护模式： 我们从名称上也能看出来，它的重点在于对数据的一种保护，而不是实现可用性 服务器角色： 主体服务器 镜像服务器 应用场景： 高的数据完整性要求 不要求自动故障转移 对服务的可用性要求较低 也就是说主体数据库的宕机还是可以接受的，但是数据的丢失是不可以接受的，那么这种场合可以使用高级别保护模式 因为没有见证服务器，所以是不能进行自动的故障转移的。那如果主体服务器不可用，那么想实现故障转移，只能是手工完成，所以对服务器的可用性要求较低 高性能模式： 服务器角色： 主体服务器 镜像服务器 应用场景： 主体服务器和镜像服务器距离很远的时候 十几公里或是完全两个城市 通讯链路有明显的延迟 对性能的要求高于数据的完整性 原理是：当主体服务器收到用户的 *** 作后，将此事务传给镜像服务器，因此距离远所以有明显的延迟，所以他不会等镜像服务器的确认，也就是说它不管这个数据到底有没有写到镜像服务器，所以这种模式就在于尽快的响应用户的请求，也就是对用户对性能有一个较高的要求，这个要求是高于数据的完整性。 这种模式下会存在数据的丢失，也就是说如果主体服务器宕机了，我们会把镜像服务器作为主体服务器，但是不能保证这里面的数据就是和主体服务器上的数据是一致的，因为有可能会有丢失。 我们对几个概念简单的介绍一下： 事务安全性： FULL 主体和镜像数据库同步传输的模式， 主体在发送日志后等待镜像的确认 主体和镜像的日志完全一致 OFF 主体和发送日志后不等待镜像的确认，继续处理后继的 *** 作。 主体失败时在镜像上可能丢失部分数据 仲裁：在高可用性或是高级别保护模式下需要仲裁。以决定那一个服务器是主体服务器， 仲裁的改变将导致故障转移，如主体服务器发生故障了，则会发生仲裁的改变，将镜像服务器定为主体服务器。 形成仲裁的形式一般有这么几种： 下面我们就来看一下如何配置数据库镜像： 这应该是大家感觉很兴奋的，因为听我西里哗拉的讲了半天。终于不用再受罪了。其实配置很简单的，只要注意几个步骤就行了。 准备镜像数据库 在镜像服务器上准备镜像数据库 创建数据库镜像端点 在各个服务器上配置镜像端点 配置安全性 启动数据库镜像 下面我们就具体看一下如何去做，有哪些需要注意： 这里需要提到的一点的就是在SQL SERVER2005刚刚发布出来的时候数据库镜像这个服务默认是关闭的，也是不支持的。在刚刚发布SQL SERVER2005正式版本的时候，认为数据库镜像这个技术还不成熟，有待完善。所以如果你使用的是正式版本则无法使用这个技术。 那么需要下载SP1或是以上的补丁。 · 版本号 sql server 2005 版本 9001399 sql server 2005（初始版本） 9002047 sql server 2005 SP1 9003042 sql server 2005 SP2 我们这里直接打SP2补丁：略 准备数据库： 条件 很重要： 主体数据库必须是完全恢复模式 创建镜像数据库 在主体数据库上做一个完全备份，在镜像服务器上使用NORECOVER选项恢复主体数据库。 继续恢复后续日志备份（NORECOVER） NORECOVER 很重要 配置数据库镜像端点 （ENDPOINT） 数据库镜像端点实现镜像会话的通讯，也就是各个服务器的入口点，有点类似于端口号。但不是。也就是说你创建了这个端点之后，各个服务器之间就可以使用TCP协议进行实例间的通讯。每个镜像端点上都在一个唯一的TCP端口号上侦听，一般大家都使用5022号端口。 创建数据库镜像端点： 需要在每个实例上创建 只有管理员组的成员才能权限。 设置端点角色 即有的是伙伴端点，有的是见证端点，所以必须要指定。 激活端点 默认是不能使用的，所以要激活。 下面我们看一下使用T-SQL 语句创建端点 CREATE ENDPOINT DBMIRRORING AS TCP（LISTENER_PORT=5022）当然也可以使用其他端口，只要没有被使用 FOR DATABASE_MIRRORING(ROLE=PARTNER,ENCRYPTION=SUPPORTED) GO -- 创建的是一个数据库镜像端点，角色是伙伴，通讯过程是通过加密的。 ALTER ENDPOINT DBMIRRORING STATE=STARTED GO --激活 此时这个端点就开始侦听了。 创建见证服务器的端点：创建的时候激活端点。 CREATE ENDPOINT DBMIRRORING STATE=STARTED AS TCP（LISTENER_PORT=5022） For DATABASE_MIRRORING (ROLE=WITNESS,ENCRYPTION=SUPPORTED) 配置安全性： 数据库镜像中的实例之间必须可信 都使用WINDOWS 身份验证或是基于证书的身份验证（非信任域），为了简单为例，我们使用WINDOWS身份验证。 赋予服务帐户对端点的连接权限。 在这里我们都使用相同的用户名口令 下面我们创建完端点后就要启动数据库镜像，注意顺序很重要 指定镜像数据库的伙伴 在镜像服务器上 *** 作 指定主体数据库伙伴 在主体服务器上 *** 作 指定见证服务器 在见证服务器上 *** 作 指定事务安全选项 FULL 还是 OFF 对应语句分别是： ALTER DATABASE NOTHWIND SET PARTNER=N'TCP：/SERVER1H:5022' –-在SERVER2（镜像）上执行 ALTER DATABASE NOTHWIND SET PARTNER=N'TCP:/SERVER2:5022' --在SERVER1（主体）上执行 ALTER DATABASE NOTHWIND SET WITNESS=N'TCP:/SERVER3:5022' --在SERVER1（主体）上执行 ALTER DATABASE NOTHWIND SET SAFETY FULL; --在SERVER1（主体）上执行 高可用性 当然也可以使用SMSS 那么完成之后怎么来查看数据库镜像是否完成，可以通过以下两种方法： SMSS 数据库属性---镜像状态 T-SQL SELECT FROM SYSDATABASE——MIRRORING SELECT FROM SYSDATABASE——MIRRORING——WITNESS 下面我们具体看一下配置高可用性数据库镜像 我们使用T-SQL 可以很明显的看到配置的过程。 下面我来介绍一下我们所使用的环境： SERVER1为主体服务器 SERVER2为镜像服务器 SERVER3 为见证服务器 首先我们要 准备数据库：一个是备份主体数据库，一个是在镜像服务器上恢复。 所以 在SERVE1上： BACKUP DATABASE NORTHWIND TO DISK='C:\NWBAK' 在 SERVER2上： RESTORE DATABASE NORTHWIND FROM DISK='C:\NWBAK' WITH NORECOVERY 创建数据库端点： 1． 在SERVER1上创建数据库镜像端点，用于伙伴通讯 Create endpoint dbmirrep as tcp (listener_port=5022) For database_mirroring (role=partner,encryption=supported ); Alter endpoint dbmirrep state=started 通过图形界面可以查看到 2． 在SERVER2上创建数据库端点，也是用于伙伴通讯 Create endpoint dbmirrep as tcp (listener_port=5022) For database_mirroring (role=partner,encryption=supported) Alter endpoint dbmirrep state=started 3． 在SERVER3上创建镜像端点，用于见证通讯 CREATE ENDPOINT DBMIRREP AS TCP （LISTENER_PORT=5022） FOR DATABASE_MIRRORING (role=witness,encryption=supported) ALTER ENDPOINT DBMIRREP STATE=STARTED 4． 检查端点配置 SELECT FROM SYSDATABASE_MIRRORING_ENDPOINTS 也可以通过图形界面查看 配置数据库镜像安全性：也就是指定哪些用户可以使用这个端点。肯定是管理员，一般用户不让他访问。 分别执行: Grant connect on endpoint::"dbmirrep" to "server1\dufei" Grant connect on endpoint::"dbmirrep" to "server2\dufei" Grant connect on endpoint::"dbmirrep" to "server3\dufei" 最后一个就是启动数据库镜像。注意：顺序 首先要从镜像服务上配置 在SERVER2上，指定伙伴端点： ALTER DATABASE ITET SET PARTNER='TCP://SERVER1:5022' 在SERVER1上，指定伙伴端点： ALTER DATABASE itet SET PARTNER='TCP://SERVER2:5022' –查看数据库 --到此为止，就是咱们前面所介绍的高级别保护模式。可以实现数据完整性，但是不能实现高可用性。所以还要继续，也就是说到这里为止，不要见证服务器也可以，但是不能实现故障的自动转移： 在 SERVER1上，指定见证服务器端点： Alter database ITET set wiTness=N'TCP://SERVER3:5022' 设置数据库镜像事务安全级别： ALTER DATABASE ITET SET SAFETY FULL 实验结束,但一定要注意细节 最后看一下数据库镜像角色切换：也就是如何实现故障转移 自动故障转移： 只针对高可用性模式 SAFETY=FULL 测试：禁用主服务器的网卡，查看库状态，再启用再查看 我们到这里已经知道了如何实现数据库镜像，那么用户如何来使用：客户端都是连接到主体服务器上进行工作的。那么如果主体服务器不可用了，那么就会造成用户连接的失败，它怎么知道去自动连接镜像服务器，这里一般使用ADO技术，如ASPNET 或是微软所提借的连接工具。 我们这里借助WINDOWS 的集群功能：来进行测试： SERVER1与SERVER2配置成WINDOWS集群： 实验到此结束! 本文出自 “杜飞” 博客

常用的数据模型中，不包括______。

A) 网状模型

B) 链状模型

C) 层次模型

D) 关系模型

正确答案

B

答案解析

为了反映事物本身及事物之间的各种联系，数据库中的数据必须有一定的结构，这种结构用数据模型来表示。数据库的主要模型包含三种：层次模型、网状模型、关系模型。采用某种特定数据模型的数据库管理系统开发出来的应用系统相应称为层次数据库系统、网状数据库系统、关系数据库系统，其中关系模型对数据库的理论和实践产生了很大影响，并且其使用最为广泛。

数据库系统的特点不包括：数据独立性低

数据库系统DBS（Data Base System，简称DBS）通常由软件、数据库和数据管理员组成。其软件主要包括 *** 作系统、各种宿主语言、实用程序以及数据库管理系统。

数据库由数据库管理系统统一管理，数据的插入、修改和检索均要通过数据库管理系统进行。数据管理员负责创建、监控和维护整个数据库，使数据能被任何有权使用的人有效使用。数据库管理员一般是由业务水平较高、资历较深的人员担任。

数据库系统的个体含义是指一个具体的数据库管理系统软件和用它建立起来的数据库；它的学科含义是指研究、开发、建立、维护和应用数据库系统所涉及的理论、方法、技术所构成的学科。在这一含义下，数据库系统是软件研究领域的一个重要分支，常称为数据库领域。

数据库系统是为适应数据处理的需要而发展起来的一种较为理想的数据处理的核心机构。计算机的高速处理能力和大容量存储器提供了实现数据管理自动化的条件。

以上就是关于数据库原理及应用基础的常见类型题全部的内容，包括:数据库原理及应用基础的常见类型题、哪些系统需要采用数据库镜像技术、常见的数据库模型不包括等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！