axdna's questions

我们在通过数据库解决方案中的 Azure Devops 部署数据库时遇到问题：

2022-01-26T09:10:26.6741963Z Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
2022-01-26T09:10:26.6742889Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeploymentPlanGenerator.DeploymentScriptDomGenerator.UnbindTableDatamotion(SqlTable sourceTable, SqlTable targetTable, Boolean unbindPartitionScheme, HashSet`1 unboundColumns)
2022-01-26T09:10:26.6744135Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeploymentPlanGenerator.DeploymentScriptDomGenerator.GenerateUnbindTableSteps(SqlTable sourceTable, SqlTable targetTable)
2022-01-26T09:10:26.6746179Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeploymentPlanGenerator.DeploymentScriptDomGenerator.GenerateSteps(Int32 operation, IModelElement element)
2022-01-26T09:10:26.6747124Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.Analyzers.PlanMediator.BuildDependencyOrderedSteps(Int32 operation, List`1 classOrder, List`1 operationOrder, Dictionary`2 changes, Boolean preserveGraphs, Dictionary`2& relating, Dictionary`2& related)
2022-01-26T09:10:26.6747886Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.Analyzers.PlanMediator.BuildOperations()
2022-01-26T09:10:26.6748373Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeploymentPlanGenerator.OnGeneratePlan()
2022-01-26T09:10:26.6748954Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeploymentPlanGenerator.GeneratePlan(List`1 drops)
2022-01-26T09:10:26.6749433Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeployment.BuildPlan()
2022-01-26T09:10:26.6749865Z    at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeployment.Controller.CreatePlan()
2022-01-26T09:10:26.6750293Z    at Microsoft.SqlServer.Dac.DeployOperation.<>c__DisplayClass3.<>c__DisplayClass5.<CreatePlanInitializationOperation>b__1()
2022-01-26T09:10:26.6750692Z    at Microsoft.Data.Tools.Schema.Sql.Dac.OperationLogger.Capture(Action action)
2022-01-26T09:10:26.6751115Z    at Microsoft.SqlServer.Dac.DeployOperation.<>c__DisplayClass3.<CreatePlanInitializationOperation>b__0(Object operation, CancellationToken token)
2022-01-26T09:10:26.6751530Z    at Microsoft.SqlServer.Dac.Operation.Microsoft.SqlServer.Dac.IOperation.Run(OperationContext context)
2022-01-26T09:10:26.6751996Z    at Microsoft.SqlServer.Dac.ReportMessageOperation.Microsoft.SqlServer.Dac.IOperation.Run(OperationContext context)
2022-01-26T09:10:26.6752488Z    at Microsoft.SqlServer.Dac.OperationExtension.CompositeOperation.Microsoft.SqlServer.Dac.IOperation.Run(OperationContext context)
2022-01-26T09:10:26.6752950Z    at Microsoft.SqlServer.Dac.OperationExtension.CompositeOperation.Microsoft.SqlServer.Dac.IOperation.Run(OperationContext context)
2022-01-26T09:10:26.6753456Z    at Microsoft.SqlServer.Dac.DeployOperation.Microsoft.SqlServer.Dac.IOperation.Run(OperationContext context)
2022-01-26T09:10:26.6753964Z    at Microsoft.SqlServer.Dac.OperationExtension.Execute(IOperation operation, DacLoggingContext loggingContext, CancellationToken cancellationToken)
2022-01-26T09:10:26.6754586Z    at Microsoft.SqlServer.Dac.DacServices.InternalDeploy(IPackageSource packageSource, Boolean isDacpac, String targetDatabaseName, DacDeployOptions options, CancellationToken cancellationToken, DacLoggingContext loggingContext, Action`3 reportPlanOperation, Boolean executePlan)
2022-01-26T09:10:26.6757007Z    at Microsoft.SqlServer.Dac.DacServices.Deploy(DacPackage package, String targetDatabaseName, Boolean upgradeExisting, DacDeployOptions options, Nullable`1 cancellationToken)
2022-01-26T09:10:26.6757864Z    at Microsoft.Data.Tools.Schema.CommandLineTool.DacServiceUtil.<>c__DisplayClassd.<DoDeployAction>b__2(DacServices service)
2022-01-26T09:10:26.6758615Z    at Microsoft.Data.Tools.Schema.CommandLineTool.DacServiceUtil.ExecuteDeployOperation(CommandLineArguments cmdlineArgs, String connectionString, String filePath, String modelFilePath, MessageWrapper messageWrapper, Boolean sourceIsPackage, Boolean targetIsPackage, Boolean authType, String tenantId, String customAuthArgs, Func`1 generateScriptFromPackage, Func`2 generateScriptFromDatabase)
2022-01-26T09:10:26.6759486Z    at Microsoft.Data.Tools.Schema.CommandLineTool.DacServiceUtil.DoDeployAction(DeployArguments deployArgs, Action`1 writeError, Action`2 writeMessage, Action`1 writeWarning, CancellationToken cancellationToken, CommandLineArguments cmdlineArgs)
2022-01-26T09:10:26.6760035Z    at Microsoft.Data.Tools.Schema.CommandLineTool.Program.DoDeployActions(CommandLineArguments parsedArgs)
2022-01-26T09:10:26.6760422Z    at Microsoft.Data.Tools.Schema.CommandLineTool.Program.PerformAction(CommandLineArguments parsedArgs)
2022-01-26T09:10:26.6760761Z    at Microsoft.Data.Tools.Schema.CommandLineTool.Program.Run(String[] args)
2022-01-26T09:10:26.6761067Z    at Microsoft.Data.Tools.Schema.CommandLineTool.Program.Main(String[] args)

同样奇怪的是，当我们在空数据库上部署项目时一切正常。当我们想在现有数据库上部署时，问题就开始了。

我正在构建的数据库的要求之一是预测数据库大小以便为生产环境准备硬件。一个应用程序有 2 个分区的主表。表在8 Filegroups (16 files, 32 partitions). 这两个表都存储了上个月的数据（一个月后数据将被删除）。我们必须12每天在一张桌子上准备36好几百万行，在第二张桌子上准备好几百万行。我对这些表进行了工作负载测试，并且：

1. 对于 100 万行，包含数据的文件组的数据大小约为13 GB
2. 对于 1200 万行，包含数据的文件组的数据大小约为48,5 GB

日志大小仅增加了40mb.

根据这个数据有两个问题：

1. 我的想法是让每天的工作量增加 30 倍。但根据上面的数据，它不是那样工作的。13*12 != 48,5
2. 为什么日志只增加40 mb了数据？
3. 如果我们将数据存储在 AlwaysOn 解决方案中，大小有什么不同吗？

为了测量文件大小，我使用了以下查询：

SELECT [sizing].[DbName],
       [sizing].[FileName],
       [sizing].[type_desc],
       [sizing].[CurrentSizeMB],
       [sizing].[FreeSpaceMB],
       [CurrentSizeMB] - [FreeSpaceMB] AS [SizeStored]
FROM
(
    SELECT DB_NAME() AS [DbName],
           [name] AS [FileName],
           [type_desc],
           [size] / 128.0 AS [CurrentSizeMB],
           [size] / 128.0 - CAST(FILEPROPERTY([name], 'SpaceUsed') AS int) / 128.0 AS [FreeSpaceMB]
    FROM [sys].[database_files]
    WHERE [type] IN ( 0, 1 )
) [sizing];

我想有一个持久化的列，它将根据varchar表中的关键列之一随机分组 32 个组的数据。我的想法是：

SELECT ABS(CAST(HASHBYTES('MD5',[keyColumnFromTable]) AS bigint) % 31)

问题：

1. CHECKSUM除了（不同的值不同COLLATE）和自己的功能之外，还有什么更好的方法吗？
2. 如果我会使用会有什么不同SELECT CAST(HASHBYTES('MD5',[keyColumnFromTable]) AS tinyint) % 31？我正在阅读它CAST正在tinyint考虑最后一个字节的数据。对随机性有影响吗？

目前，我有一个程序可以在以下位置执行 4 个操作Transaction：

1. 更新表中的记录A
2. 更新表中的记录B
3. 向表中插入记录C
4. 从表中删除记录D

@IsUpdateA只有当procedure ( ) 的一个参数等于1时，才执行第一个操作。

因此，从业务角度来看，如果@IsUpdateA= 1，则必须执行表 A 的更新，而始终执行第 2、3 和 4 步。

问题是将这样的程序分成两部分是否更好（就效率/执行计划而言），即

1. 第一个程序将始终执行步骤 1、2、3、4
2. 第二个程序将始终执行步骤 2,3,4

并将@IsUpdateA在应用程序中进行检查。我不能在程序中使用程序（内部要求）。

我的数据库中有五个域用户和五个角色。GRANT EXECUTE添加到适当的角色。角色包含在其他角色中，即最多我们有一个角色拥有两个程序的授权，下面还有两个角色可以访问四个和三个程序，最后我们有两个角色。使用此解决方案，如果我将GRANT EXECUTE权限授予最高角色，则所有角色都可以访问此过程。

我的问题：假设程序有UPDATE和INSERT操作。对于给定角色的给定过程是否足够，GRANT EXECUTE以便用户可以使用该过程并实际在表上执行UPDATE和INSERT操作，或者除了GRANT EXECUTE我需要授予角色UPDATE和INSERT给定过程中的所有表之外？

我有一个csv包含 350,000 行的文件。想以与csv文件中相同的顺序将数据插入临时表。我正在尝试BULK INSERT使用：

BULK INSERT ##AllRows
    FROM @FilePath
    WITH
    (
    FIELDTERMINATOR = '\n'
    )

不幸的是BULK INSERT，以随机顺序插入数据。我每次执行的标题都在不同的行中。我在 SQL Server 2016 上运行它。是否有可能在旧版本的 SQL Server 中顺序方式不同？

使用该FIRSTROW选项不会将标题识别为文件的第一行。文件没有我们可以订购的任何列。在文件中，标题总是在第一行。

这可能是巧合，但即使FIRSTROW=2我的标题有可能出现在表格中。我检查了它。看起来csv文件中包含的行越多，插入到表中的可能性就越大。