我有一个基本上像这样的源表：
实际的表格每个工作日有大约 500 个编号的列（并没有真正计算它们 - 有各种各样的编号为 1-7 的字段，然后是另外一些编号为 1-25，乘以 7 的字段（不，那不是我的设计） ，目前大约有 38,600 行（每周增长）。
我有一个 SSIS 包试图规范化这些数据......目前看起来像这样：
每个“源”从同一个源表中选择一组编号的列，UNION ALL 组件将 7 个源合并为一个，产生大约 258,900 行。
工作流的其余部分添加一些计算列，查找代理键（例如EmployeeCode用于查找EmployeeId，然后计算日期并用于查找 a TimeId），然后更新“修改”行和“新”行一个被插入到一个规范化的表中；未更改的行最终无处可去。
有没有更好的方法（例如，减轻内存压力）来规范化源数据？
我不是 DBA，但事情就是这样，我必须戴上 DBA 的帽子并在我的 SQL Server 实例上设置维护计划。
所以一段时间以来，我一直让我的 SSIS 通宵进程运行Execute SQL Task来执行备份 - 基本上是运行master.dbo.xp_create_subdir以确保目标文件夹存在，然后BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.
每当该任务失败时，该过程的其余部分将中止，并且我会收到通知，并在第二天早上注意到事务日志的驱动器已满载，因此我将手动截断它们并继续前进。 ..直到故事重演并且事务日志再次超出可用磁盘空间。
“手动截断”脚本如下所示：
use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go
所以我越来越厌倦了，我决定尝试正确地做事，并按照这里的步骤创建一个实际的维护计划：
问题是，我以前从未这样做过，所以我有几个问题：
G:\Backups。那有意义吗？抱歉，如果一篇文章的问题太多了，如果需要，我会编辑并提出多个问题 - 我认为它们都是紧密相关的。
我的 SSIS 控制流中有一个执行 SQL 任务，它在继续运行通宵 ETL 之前备份了许多数据库：
EXECUTE master.dbo.xp_create_subdir N'G:\Backups\DQ'
GO
EXECUTE master.dbo.xp_create_subdir N'G:\Backups\master'
GO
EXECUTE master.dbo.xp_create_subdir N'G:\Backups\Metadata'
GO
EXECUTE master.dbo.xp_create_subdir N'G:\Backups\NDS'
GO
EXECUTE master.dbo.xp_create_subdir N'G:\Backups\Staging'
GO
BACKUP DATABASE [DQ] TO DISK = N'G:\Backups\DQ\DQ.bak' WITH RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'DQ', SKIP, REWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [master] TO DISK = N'G:\Backups\master\master.bak' WITH RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'master', SKIP, REWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [Metadata] TO DISK = N'G:\Backups\Metadata\Metadata.bak' WITH RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'Metadata', SKIP, REWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [NDS] TO DISK = N'G:\Backups\NDS\NDS.bak' WITH RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'NDS', SKIP, REWIND, NOUNLOAD, STATS = 10
GO
BACKUP DATABASE [Staging] TO DISK = N'G:\Backups\Staging\Staging.bak' WITH RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'Staging', SKIP, REWIND, NOUNLOAD, STATS = 10
目的是只保留 3 天，并丢弃任何旧的。
问题是 .bak 文件只会持续增长一两周，直到 G 驱动器填满并且执行 SQL 任务失败，这会中止通宵的 ETL。
看起来 .bak 显然没有丢弃旧备份；看起来我可以一直回到上次删除所有备份以释放该 G 驱动器上的一些磁盘空间：
问题很简单：看起来我的Execute SQL Task做错了。我如何解决它？或者是别的什么？
我已经构建了一个 SSIS ETL 来将各种数据源（一个来自 MySQL，两个来自 SQL Server）集成到一个 SQL Server 关系和规范化数据库中，我称之为 [NDS]。
SSIS ETL 处理类型 2 更新，因此 [NDS] 生成代理键，SCD 表包含一个 [_EffectiveFrom] 时间戳和一个可为空的 [_EffectiveTo] 列，并且对链接所有数据在一起。
现在，我想用它构建一个 SSAS 维度数据库，没过多久我就意识到我正在为雪花模式设置自己：
所以我正在考虑添加一个新的 [DDS]（关系）数据库，以创建实际的维度和事实表，这些表将为 SSAS 数据库提供 DSV。
这个 [DDS] 数据库将尽可能地非规范化，以便将事实和维度“扁平化”（例如，[OrderHeaders]+[OrderDetails] 到 [Orders] 事实表，以及 [CustomerStores]+[Customers]+ [SalesReps] 到一些 [Customers] 维度表中）——这样做不仅可以让我更容易地在 SSAS 中构建维度层次结构，还可以更容易地提出一个实际的星型模式。
我有几个问题：
我是在为 Big Mess™ 做准备，还是在正确的轨道上？
我正在使用 SSAS 设置我的第一个维度数据库，并且我有这个 [Materials] 维度需要一个像这样的层次结构：
[PriceCode v] --> nullable
Price Code
...
[Material v]
Code
AltCode
Name
...
[Id v] --> not actually exposed as a hierarchy level
DateInserted
DateUpdated
DateDeleted
EffectiveFrom
EffectiveTo
问题是该[PriceCode]属性可以为空；DSV 在 a[Materials]和[PriceCodes]表之间有一个外键，并且[Materials].[PriceCodeId]可以为空。
有没有办法仍然定义可空属性是父级的层次结构？我摆弄过UnkownMember和UnknownMemberName以及属性键的NullProcessing设置，但无法获得要处理的维度。
如果有人可以通过基于业务键（即Code字段；自然键包括EffectiveTo字段，null用于记录的当前图像）创建层次结构来确认我是否正在正确处理缓慢变化的维度问题，则加分，并将 SCD 元数据视为其自身的一个级别。
作为大型 SSIS 部署的一部分，我有两个 SSIS 包在夜间运行（通过 SQL Server 代理），没有任何问题。一切都使用 Windows 身份验证，并且计划的作业由系统管理员（好吧，我）拥有并作为SQL Server 代理服务帐户运行。
因此，数据基本上是source system ~> transit db ~> staging ~> NDS一夜之间的。
我关心的两个 SSIS 包分别处理特定数据集的transit db ~> staging和部分。staging ~> NDS
域用户（非系统管理员）在 中执行某些操作source system，并将感兴趣的数据推送到 中transit db，因此我需要一种在工作时间获取更新数据的方法来更新NDS：决定此人触发的最简单方法该 ETL 是通过单击启用宏的 Excel 工作簿中的按钮，该工作簿通过 ODBC（使用 Windows 身份验证）连接到 SQL Server 并执行存储过程。
存储过程如下所示：
create procedure dbo.UpdateMaterialInventory
as
begin
execute msdb.dbo.UpdateMaterialInventory;
end
[msdb] 中的“姐妹”存储过程如下所示：
create procedure dbo.UpdateMaterialInventory
with execute as 'SqlAgentProxy'
as
begin
execute msdb.dbo.sp_start_job N'NDS-ManualMaterialInventory';
end
这个 [SqlAgentProxy] 用户是我在域用户登录的 [msdb] 中创建的 Windows 用户，我授予execute了此UpdateMaterialInventory过程的权限。这避免了必须授予域用户execute权限msdb.dbo.sp_start_job，这将是过度的。
SQL 代理作业NDS-ManualMaterialInventory归域用户所有，有 2 个步骤，每个步骤类型为 [SQL Server Integration Services Package]，设置为Run as SSISProxy。
SSISProxy是一个 SQL Server 代理代理，它使用 credential name 映射到 [SQL Server Integration Services Package] 子系统SSISProxyCredentials。域用户的登录已添加到代理帐户 principals。
它们是使用在夜间运行整个 SSIS ETL 的同一域用户的身份创建的，并且其密码经过四重检查SSISProxyCredentials。
现在，如果我运行这个：
execute as login=N'DOMAIN\thatperson'
exec NDS.dbo.UpdateMaterialInventory;
go
我得到这个输出：
Job 'NDS-ManualMaterialInventory' started successfully.
然而，工作经历讲述了一个不那么令人鼓舞的故事：
The job failed. The Job was invoked by User DOMAIN\thatperson.
The last step to run was step 1 (Extract).
第 1 步详细信息：
Executed as user: {domain user that runs SSIS ETL overnight}.
Microsoft (R) SQL Server Execute Package Utility Version 12.0.4100.1 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started: 2:18:50 PM Failed to execute IS server package because of error 0x80131904.
Server: {server name}, Package path: \SSISDB\Foo\Bar\foobar.dtsx, Environment reference Id: NULL.
Description: Login failed for user '{domain user that runs SSIS ETL overnight}'.
Source: .Net SqlClient Data Provider
Started: 2:18:50 PM Finished: 2:18:51 PM Elapsed: 0.094 seconds.
The package execution failed.
The step failed.
作业失败，任何地方都没有记录任何内容。
如果我将作业所有者更改为我自己，并将步骤的运行更改为SQL Server 代理服务帐户，作业将运行、成功并将 1,067 行记录到 [Metadata].[dbo].[sysssislog]。
看起来代理/凭据的设置方式有些不对劲。我做错了哪一部分？
我无法控制的一个过程是每晚在 MySQL 数据库中删除和重新创建表。如果它每次都以相同的方式重新创建表，这将不是问题（我认为）。但事实并非如此：每天早上我进来打开我的 SSIS 项目，然后我在随机表/列中收到新的元数据验证错误/警告，因为这个通宵的过程正在创建varchar长度根据数据而变化的列，所以昨天我有一个长度为 90 的列，今天同一张表中的同一列现在有 208 的长度，明天可能是一个不同的故事......或不是。
这个 MySQL 数据库是我的主要数据源——我在 SQL Server 上有我的暂存数据库，并且通过链接服务器连接，我正在使用 SSIS 从这些表中选择数据并输入到 SQL Server 表中（添加了一些列），这在用远程数据填充它们之前，我正在截断它们（因此此登台数据库中的元数据是固定的）。
为什么 SSIS 需要验证外部元数据？如果我关闭设计时验证，它说它被延迟到运行时 - 这是否意味着我只会将问题从设计时推到运行时，并且仍然得到一个失败的包？
我有一个 T-SQL 脚本，可以执行从 MySQL 到 SQL Server 暂存表的数据传输，但该脚本运行大约 45 分钟，而 SSIS 包，当所有元数据都是最新的时，运行大约 5分钟 - 不用说，我更喜欢找到一种方法让 SSIS 停止抱怨过时的元数据，而不是使用该脚本。
有没有办法在 SSIS 中使用这种数据源的变形器并保持理智？
我正在设计一个 Staging+NDS+DDS 数据仓库系统，其中 ETL 将规范化数据[Staging]并将其加载到[NDS]，它将保存所有历史记录。
我几乎完成了将在[NDS]数据库中创建表和约束的 T-SQL 脚本，其中包含主表和事务表，它们将分别以我打算成为星型模式的形式提供[DDS] 维度表和事实表。
我给自己制定了以下规则：
[DDS]维度以DWD_[DDS]事实以DWF_DWK_DWD_Key一张DWD_桌子，或DWF_Key一张DWF_桌子。DWD_Customers表具有控制列：
DWD_IsLastImageDWD_EffectiveFromDWD_EffectiveToDWD_DateInsertedDWD_DateUpdatedDWD_DateDeletedDWF_InvoiceHeaders表具有控制列：
DWF_DateInsertedDWF_DateUpdatedDWF_DateDeletedPK_后跟表名（包括表前缀）——例如PK_DWD_Customersand PK_DWF_InvoiceHeaders。unique上添加了一个约束，它们总是以 with 为前缀，后跟表名（包括表前缀）——例如and 。NK_NK_DWD_CustomersNK_DWF_InvoiceHeadersDWK_后跟引用表的名称（不带前缀）和“Key”一词 - 例如DWK_CustomerKey。FK_[ParentTableNameWithPrefix]_[ChildTableNameWithPrefix]。FK_DWD_FiscalCalendar_DWF_OrderDetails_DeliveryDate.所有带前缀的列都没有业务意义，不应该出现在视图中；我发现，这给我留下了一个非常干净和一致的设计，以及create table如下所示的脚本：
create table DWD_SubCategories (
DWD_Key int not null identity(1,1)
,DWD_DateInserted datetime not null
,DWD_DateUpdated datetime null
,DWK_CategoryKey int not null
,Code nvarchar(5) not null
,Name nvarchar(50) not null
,constraint PK_DWD_SubCategories primary key clustered (DWD_Key asc)
,constraint NK_DWD_SubCategories unique (Code)
);
所以，我的问题是，在我继续并实施 ETL 以将数据加载到该数据库之前，有什么我应该知道（或忘记）的吗？以后会不会有人继承这个数据库来追杀我的脑袋？我应该改变什么来避免这种情况？我询问前缀的原因是因为我正在使用DWDand DWF，但这些表在技术上不是“维度”和“事实”表。这令人困惑吗？
此外，我不确定自然键的概念- 我是否正确地假设它应该是源系统可能认为其“键”列的唯一列组合，我可以在 ETL 过程中使用它来定位，比如说, 要更新的特定记录？