sqlserver2000数据库数据转移

Posted 2023-05-08

因为网站要改版，原先的数据大概有好几万，而且表多大180多张，每张表几乎都有外键相关联，网站本身不难，但是数据量巨大，关系复杂，请教数据库达人，如何才能做好主外键的联系，而在导数据的过程中不出错呢
结构可能要改动，因为原来的数据库设计和写法严重影响了效率，在这种情况下，如何做到各个表主外键id对应呢，在结构改动的情况下迁移数据，如何才能不出错

参考技术A 你用powerdesigner 逆向工程 得到数据库结构表
建立个新数据库
然后将不要的关系以及表删除掉

然后使用 selete into 语法对应将老数据库德插入到新数据库里面来
其实也挺快的
如果你的主见都是自增ID 设置下
SET IDENTITY_INSERT 表名on
selete into 插入语句
SET IDENTITY_INSERT 表名OFF

希望对你有帮助 参考技术B 要保证原来表的结构和关系不变,最好采用分离附加或者备份还原的方式进行迁移.本回答被提问者采纳

005.SQLServer AlwaysOn可用性组高可用简介

一 AlwaysOn 可用性组

1.1 AlwaysOn 可用性组概述

AlwaysOn 可用性组功能是一个提供替代数据库镜像的企业级方案的高可用性和灾难恢复解决方案。SQL Server 2012 中引入了 AlwaysOn 可用性组功能，此功能可最大程度地提高一组用户数据库对企业的可用性。 “可用性组”针对一组离散的用户数据库（称为“可用性数据库”，它们共同实现故障转移）支持故障转移环境。

一个可用性组支持一组读写主数据库以及一至四组对应的辅助数据库。可使辅助数据库能进行只读访问和/或某些备份操作。

可用性组在可用性副本级别进行故障转移。故障转移不是由诸如因数据文件丢失而使数据库成为可疑数据库、删除数据库或事务日志损坏等此类数据库问题导致的。

1.2 AlwaysOn 可用性组的优点

优点：

AlwaysOn 可用性组提供了一组丰富的选项来提高数据库的可用性并改进资源使用情况。 主要组件如下：

• 支持最多五个可用性副本

“可用性副本”是可用性组的实例化，此可用性组由特定的 SQL Server 实例承载，该实例维护属于此可用性组的每个可用性数据库的本地副本。 每个可用性组支持一个主副本和最多四个辅助副本。

说明：每个可用性副本都必须驻留在单个 Windows Server 故障转移群集 (WSFC) 群集的不同节点中。

• 支持替代可用性模式，如下所示：

• 异步提交模式。 此可用性模式是一种灾难恢复解决方案，适合于可用性副本的分布距离较远的情况。
• 同步提交模式。 此可用性模式相对于性能而言更强调高可用性和数据保护，为此付出的代价是事务延迟时间增加。一个给定的可用性组可支持最多三个同步提交可用性副本（包括当前主副本）。
• 支持几种形式的可用性组故障转移

自动故障转移、计划的手动故障转移（通常简称为“手动故障转移”）和强制的手动故障转移（通常简称为“强制故障转移”）。

• 将特定的可用性副本配置为支持以下一种或两种活动辅助功能：

• 利用只读连接访问，与副本的只读连接可以在此副本作为辅助副本运行时访问和读取其数据库。
• 当副本作为辅助副本运行时，对副本的数据库执行备份操作。

提示：通过使用活动辅助功能，可更好地利用辅助硬件资源，从而提高 IT 效率并降低成本。 此外，通过将读意向应用程序和备份作业转移到辅助副本，有助于提高针对主副本的性能。

• 支持每个可用性组的可用性组侦听器

“可用性组侦听器”是一个服务器名称，客户端可连接到此服务器以访问 AlwaysOn 可用性组的主副本或辅助副本中的数据库。可用性组侦听器将传入连接定向到主副本或只读辅助副本。侦听器在可用性组故障转移后提供快速应用程序故障转移。

• 支持灵活的故障转移策略以便更好地控制可用性组故障转移
• 支持用于避免页损坏的自动页修复
• 支持加密和压缩，这提供了安全且高性能的传输方式
• 提供了一组集成的工具来简化部署和管理可用性组，这些工具包括：

• 用于创建和管理可用性组的 Transact-SQL DDL 语句
• SQL Server Management Studio 工具：

• 新建可用性组向导 创建和配置可用性组。 在某些环境中，此向导还可以自动准备辅助数据库并且为每个数据库启动数据同步。
• 将数据库添加到可用性组向导 向现有可用性组添加一个或多个主数据库。 在某些环境中，此向导还可以自动准备辅助数据库并且为每个数据库启动数据同步。
• 将副本添加到可用性组向导 向现有可用性组添加一个或多个辅助副本。 在某些环境中，此向导还可以自动准备辅助数据库并且为每个数据库启动数据同步。
• 故障转移可用性组向导 启动对可用性组的手动故障转移。 根据您指定为故障转移目标的辅助副本的配置和状态，该向导可以指定计划的手动故障转移或强制手动故障转移。

• AlwaysOn 面板 监视 AlwaysOn 可用性组、可用性副本和可用性数据库，并且评估 AlwaysOn 策略的结果。
• “对象资源管理器详细信息”窗格显示有关现有可用性组的基本信息。
• PowerShell cmdlet。 有关详细信息，请参阅 AlwaysOn 可用性组的 PowerShell Cmdlet 概述 (SQL Server)。

1.3 AlwaysOn术语和定义

• 可用性组 (availability group)

一个容器，用于一组共同实现故障转移的数据库（称为“可用性数据库”，它们共同实现故障转移）。

• 可用性数据库 (availability database)

属于可用性组的数据库。 对于每个可用性数据库，可用性组将保留一个读写副本（“主数据库”）和一个到四个只读副本（“辅助数据库”）。

• 主数据库 (primary database)

可用性数据库的读写副本。

• 辅助数据库 (secondary database)

可用性数据库的只读副本。

• 可用性副本 (availability replica)

可用性组的实例化，该可用性组由特定的 SQL Server 实例承载，并维护属于该可用性组的每个可用性数据库的本地副本。存在两种类型的可用性副本：一个“主副本”和一至四个“辅助副本”。

• 主副本 (primary replica)

可用性副本使主数据库可用于来自客户端的读写连接，还用于将每个主数据库的事务日志记录发送到每个辅助副本。

• 辅助副本 (secondary replica)

维护各可用性数据库的辅助副本的可用性副本，充当可用性组的潜在故障转移目标。 或者，辅助副本可以支持对辅助数据库进行只读访问，并支持对辅助数据库创建备份。

• 可用性组侦听器 (availability group listener)

一个服务器名称，客户端可连接到此服务器以访问 AlwaysOn 可用性组的主副本或辅助副本中的数据库。可用性组侦听器将传入连接定向到主副本或只读辅助副本。

二 可用性副本

每个可用性组定义一个包含两个或更多故障转移伙伴（称为可用性副本）的集合。“可用性副本”是可用性组的组件。每个可用性副本都承载可用性组中的可用性数据库的一个副本。对于某个给定可用性组，可用性副本必须位于某一 WSFC 群集的不同节点上的单独 SQL Server 实例上。必须为 AlwaysOn 启用这些服务器实例中的每个实例。

对于每个可用性组，一个给定实例只能承载一个可用性副本。但是，每个实例可用于多个可用性组。给定的实例可以是独立实例或 SQL Server 故障转移群集实例 (FCI)。如果您要求服务器级别的冗余，则使用故障转移群集实例。

每个可用性副本都被分配一个初始角色（“主角色”或“辅助角色”），角色由该副本的可用性数据库继承。给定副本的角色确定它承载的是读写数据库还是只读数据库。其中一个副本（称为“主副本”）被分配主角色，它承载读写数据库（称为“主数据库”）。至少一个其他副本（称为“辅助副本”）被分配辅助角色。辅助副本承载只读数据库（称为辅助数据库）。

三 可用性模式

可用性模式是每个可用性副本的一个属性。可用性模式确定主副本是否在给定的辅助副本将事务日志记录写入磁盘（强制写入日志）之前，等待提交数据库上的事务。AlwaysOn 可用性组支持两种可用性模式：“异步提交模式”和“同步提交模式”。

• 异步提交模式

使用此可用性模式的可用性副本称为“异步提交副本”。在异步提交模式下，主副本无需等待确认异步提交辅助副本已强制写入日志，便可提交事务。异步提交模式可最大限度地减少辅助数据库上的事务滞后时间，但允许它们滞后于主数据库，因此可能会导致某些数据丢失。

• 同步提交模式

使用此可用性模式的可用性副本称为“同步提交副本”。在同步提交模式下，在提交事务之前，同步提交主副本要等待同步提交辅助副本确认它已完成强制写入日志。同步提交模式可确保在给定的辅助数据库与主数据库同步时，充分保护已提交的事务。这种保护的代价是延长事务滞后时间。

四 故障转移群集和 AlwaysOn 可用性组

4.1 概述

部署 AlwaysOn 可用性组需要一个 Windows Server 故障转移群集 (WSFC) 群集。若要启用 AlwaysOn 可用性组，一个 SQL Server 实例必须驻留在某一 WSFC 节点上，并且该 WSFC 群集和节点必须处于联机状态。 此外，给定可用性组的每个可用性副本必须位于相同 WSFC 群集的不同节点上。

AlwaysOn 可用性组依赖 Windows 故障转移群集 (WSFC) 群集来监视和管理属于某一指定可用性组的可用性副本的当前角色，并且确定故障转移事件是如何影响可用性副本的。为您创建的每个可用性组创建一个 WSFC 资源组。 WSFC 群集将监视此资源组，以便评估主副本的运行状况。

针对 AlwaysOn 可用性组的仲裁基于 WSFC 群集中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。与数据库镜像相反，在 AlwaysOn 可用性组中没有见证服务器角色。

WSFC 群集的总体运行状况是由群集中节点仲裁的投票决定。如果 WSFC 群集由于计划外灾难或由于持续的硬件或通信故障而导致脱机，则需要管理员手动干预。Windows Server 或 WSFC 群集管理员将需要“强制仲裁”，并在非容错配置中将仍有效的群集节点变为联机状态。

4.2 故障转移类型

在主副本和辅助副本之间的对话上下文中，通过称为“故障转移”的过程，主角色和辅助角色是潜在可互换的。 在故障转移期间，目标辅助副本转换为主角色，成为新的主副本。新的主副本使其数据库作为主数据库联机，而客户端应用程序可以连接到这些数据库。如果以前的主副本可用，则它将转换为辅助角色，成为辅助副本。以前的 master 数据库成为辅助数据库，且数据同步恢复。

有三种故障转移形式：自动、手动和强制（可能造成数据丢失）。给定辅助副本支持的故障转移形式取决于其可用性模式，对于同步提交模式来说，取决于主副本和目标辅助副本的故障转移模式，如下所示。

• 同步提交模式支持两种故障转移形式

“计划的手动故障转移”和“自动故障转移”（如果目标辅助副本当前与 avt1 同步）。对这些故障转移形式的支持取决于故障转移伙伴上的“故障转移模式属性”的设置。如果在主副本或辅助副本上将故障转移模式设置为“手动”，则对于该辅助副本仅支持手动故障转移。如果同时在主副本和辅助副本上将故障转移模式设置为“自动”，则该辅助副本同时支持自动故障转移和手动故障转移。

• 计划的手动故障转移（无数据丢失）

手动故障转移在数据库管理员发出故障转移命令之后发生，它将导致已同步的辅助副本转换为主角色（同时确保数据受到保护），而主副本转换为辅助角色。手动故障转移要求主副本和目标辅助副本都在同步提交模式下运行，并且辅助副本必须已同步。

• 自动故障转移（无数据丢失）

自动故障转移是为了响应导致已同步的辅助副本转换为主角色（同时确保数据受到保护）的故障而执行的。如果以前的主副本变为可用，则它将转换为辅助角色。自动故障转移要求主副本和目标辅助副本都在同步提交模式下运行，并且故障转移模式设置为“自动”。此外，辅助副本必须已同步并具有 WSFC 仲裁，且满足由可用性组的“灵活的故障转移策略”指定的条件。

• 在异步提交模式下，唯一的故障转移形式为强制手动故障转移（可能造成数据丢失），通称为“强制故障转移”。强制故障转移被认为是一种手动故障转移，因为它只能手动启动。强制故障转移是一个灾难恢复选项。当目标辅助副本与主副本不同步时，强制故障转移是唯一可能的故障转移形式。

五 与其他数据库引擎功能的互操作性和共存

AlwaysOn 可用性组可与以下 SQL Server 功能和组件一起使用：

• 变更数据捕获 (SQL Server)
• 更改跟踪 (SQL Server)
• 包含的数据库
• 数据库加密
• 数据库快照
• FILESTREAM
• FileTable
• 日志传送
• 远程 Blob 存储区 (RBS)
• 复制
• Service Broker
• SQL Server 代理
• Reporting Services

参考官方：https://docs.microsoft.com/zh-cn/previous-versions/sql/sql-server-2012/ms189852(v%3dsql.110)