标签: deployment

我正在尝试使用 sqlpackage.exe 实用程序部署 ssdt 项目。我收到以下错误（德语）：

Fehler bei der Erstellung des Bereitstellungsplans。Die Bereitstellung kann nicht fortgesetzt werden。元素属性-类别长度在元素-oder Annotation-Klasse PersistedResolvableAnnotation中尚无定论。

这意味着…… 喜欢：

创建部署计划时出错。部署无法继续。属性类 Length 不包含在元素或注释类 PersistedResolvableAnnotation 中。

我找不到关于“PersistedResolvableAnnotation”的很多信息。但我意识到它包含在 dacpac 的 model.xml 中。

它包含一些与此类似的 SqlLogins 定义：

<Element Type="SqlUser" Name="[Angela]">
            <Property Name="IsWithoutLogin" Value="True" />
            <Relationship Name="DefaultSchema">
                <Entry>
                    <References Name="[Angela]" Disambiguator="8" />
                    <Annotation Type="**PersistedResolvableAnnotation**" Name="[Angela]">
                        <Property Name="TargetTypeStorage" Value="SqlSchema" />
                        <Property Name="Length" Value="8" />
                        <Property Name="Offset" Value="62" />
                    </Annotation>
                </Entry>
            </Relationship>
        </Element>

Angela（和其他候选人）不作为 Login 存在于目标服务器上，尽管他们是目标数据库中的注册数据库用户。我期待另一个错误——如果有的话——而不是这个无用的错误。

该项目的数据库基于一个非常古老的 SQL Server 版本。是否有可能这是来自 Sql Server 版本的一些已弃用的功能/语法或属性，并且根本不受支持？有谁知道更多详情？

In SQL Server, I would like to create a role that has the ability to manipulate database objects as well as create other roles and grant those roles subsets of its permissions.

CREATE ROLE deploymentRole;
CREATE ROLE subRole;
GRANT SELECT TO deploymentRole WITH GRANT OPTION;

CREATE TABLE dbo.testTable (id INT NULL);
CREATE USER deployUser WITHOUT LOGIN;
ALTER ROLE deploymentRole ADD MEMBER deployUser;

EXECUTE AS USER = 'deployUser';

--This works
SELECT * FROM dbo.testTable

--This also works
GRANT SELECT TO subRole …

我们有一个由大约 129 个表组成的 Visual Studio 数据库项目。它是我们内部基于 Web 的 CRM/呼叫中心产品的主要数据库，该产品仍在积极开发中。

我们使用 VS 中的 SSDT 发布在进行更改时部署到实例。我们通过 SQL Express (2016) 在本地开发，还有一个 LAB 环境用于运行 SQL 2014 的性能和负载测试，一个运行 2012 的 UAT 环境，最后部署到运行 SQL 2016 的生产环境。

在发布时生成的脚本的所有环境（生产除外）都非常好，只做更改。生产脚本做了大量的工作。似乎删除并重新创建了更多的表，我知道这些表没有改变（上次部署了 37 个表）。其中一些表的行数以百万计，整个发布需要 25 分钟以上。

如果我重复发布到生产，它会再次删除并重新创建 37 个表。生产数据库确实有复制，我必须在部署之前禁用它（不确定这是否是一个因素）。

我不明白 Production 发布总是想要删除和重新创建表的内容，即使什么都没有改变。我希望得到一些关于在哪里寻找确定为什么 SSDT 认为需要重新创建这些的建议。

使用 Visual Studio Professional 2017 V 15.5.5 和 SSDT 15.1

从 SSDT 生成部署脚本时，它总是生成删除外键约束和索引的代码，然后再次创建这些约束和索引。生成部署脚本时如何删除删除并重新创建这些对象的代码？SSDT 中的任何选项？

我通过ansible生成postgresql配置文件，并将它们放入/etc/postgresql/XX/main/conf.d/whatever.conf. 我不小心犯了一个语法错误并破坏了我的 postgresql，需要手动修复。

是否有任何 postgresql 命令来验证文件是否是有效的 postgresql.conf 文件？

sudoers文件可以通过 进行验证/usr/sbin/visudo -cf path/to/file。有没有postgresql的东西？

我目前正在运行 Ubuntu 18.04 和 20.04，以及 PostgreSQL 10、12 等（是的，有几个不同的版本）。

在使用MS SQL Server Management Studio创建和编辑数据库一段时间后，我尝试为此使用Visual Studio 2010 “SQL Server 2008 数据库项目”。

我使用SQL 2008 向导将现有数据库导入到VS2010。一切顺利。构建也成功了。但是，当我尝试以另一个名称将数据库部署回服务器时，我收到了很多类型为"Procedure: XXXX has an unresolved reference to object XXXX" 的错误。

我很惊讶，因为所有这些存储过程实际上都运行良好，而且SQL Server Management Studio从未抱怨过它们。可能有什么问题？

我正在使用DbUp，从我创建一个 C# 程序的示例开始。该示例建议我将所有脚本放在Scripts目录下。好的，这已经完成，但是，当脚本数量增加时，该目录将变得如此混乱。

我会用版本号组织这些目录。例如

• 1.0.0（目录）
  • CS001 - 基线.sql
• 1.0.1（目录）
  • CS001 - 更改 x table.sql
  • CS002 - 创建 y procedure.sql
• 1.1.0（目录）
  • CS001 - 创建视图 z.sql

显然，代码会以有序的方式处理脚本。我怎样才能做到这一点？我在哪里找到文档和其他示例？

我现在研究了很长时间（大约两个月），还没有找到一个好的方法，所以我会请教各位专家，希望能有所启发。

我在云中运行了一个非常传统的 LAMP Web 应用程序。源代码是使用 Git 进行 VCS 处理的，以及数据库架构（拆分 SQL 文件用于结构和默认数据）。

部署新环境是一种乐趣，无论是开发还是生产。开发环境使用 Vagrant 以及我编写的一些不错的 shell 配置脚本进行部署。生产环境是使用 Vagrant 配置脚本的一个子集部署的，这也很容易做到。

当开发周期对 SQL 模式（结构或数据）进行更改时，事情开始出现问题。在这种情况下，开发人员会更改核心 SQL 脚本，以便所有更改都进入 VCS，这对于全新的环境来说是完全没问题的。

问题出在已经部署的生产环境中：对于那些，我必须手动获取 SQL 更改的所有补丁，因为修订版首先在所有生产服务器中实际运行，以便我可以在之后手动应用它们。这需要很长时间才能发生，是一项非常脆弱且容易出错的任务。

最初，我认为我可以将 SQL 更改从核心 SQL 文件的较小子集移开，让核心 SQL 文件作为起点。当 SQL 结构发生变化时，我可以告诉开发人员创建一个新的 SQL 文件，其中仅包含该开发周期中的更改。

因此，例如：

- structure_begin.sql: the SQL schema as it is now.
|- structure_devcycle1.sql: first set of changes to the structure
|- structure_devcycle2.sql: second set of changes to the structure, and so forth...

然后，通过使用 Git 钩子，我可以有选择地自动将它们部署到生产环境中。但我不知道这是否是一个好方法。在这里我可以问：

1. 有没有人解过这个谜题？
2. 生产环境中 SQL 更改的发布管理和部署自动化的最佳实践是什么？
3. 是否有任何开源工具可以在此过程中提供帮助？（我知道Sqitch，但我不太确定它是否适合这份工作。）

我将 SQLPackage.exe 与数据库发布配置文件结合使用，将数据库更改部署到 DEV 和 QC 实例。我的数据库处于简单恢复模式。但是当我使用 SQLPackage 部署更改时，它将它们恢复为完全恢复模式。

这就是我正在使用的，

"C:\Program Files (x86)\Microsoft SQL Server\110\DAC\bin\SqlPackage.exe" /Action:Publish /SourceFile:"FILE PATH TO .DACPAC" /Profile:"PUBLISH PROFILE.XML"

如果我使用 Visual Studio 使用相同的发布项目来部署项目更改，则会发生同样的情况。

我在这里缺少什么？据我所知，Profile 中没有这样的标志。这是 SQLPackage 的预期行为吗？

我在 SSDT 中有 CLR 程序集，并且部署它必须是可信的。据我所知，有 4 个选项如何做到这一点

第一个选项，使用 TRUSTWORTHY

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
  
ALTER DATABASE SourceDatabase SET TRUSTWORTHY ON;

第二个选项，禁用严格安全性

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;  
  
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;

第三个选项，使用密钥或证书对程序集进行签名

Seems complicated and I was not able to manage that yet. I will appreciate the instructions, because the workflow is not clear here.

第四个选项，使用sp_add_trusted_assembly

EXEC sp_configure 'clr enabled', 1;  
RECONFIGURE;

declare @assembly varbinary(max) = 0x4D5A90000300000004000000FFFF0000... -- …

我正在寻找一个开源工具来生成 DDL 脚本。许多工具将这些同步脚本称为。我们本质上想比较不同环境的模式（即：DEV 到 QA，QA 到 PROD）以更轻松地管理对象迁移/部署。Oracle 是否存在这样的开源工具？

Red Gate 部署管理器(RGDM) 今天失败并出现“登录失败”错误，即使它具有目标服务器的管理控制权：

2013-11-04 17:13:22 +00:00 INFO   Creating [dbo].[GetPublications]
2013-11-04 17:41:29 +00:00 INFO   Command RedGate.Deploy.Agent.Commands.SingleShotDeploymentCommand failed
2013-11-04 17:41:29 +00:00 INFO   RedGate.Deploy.PluginApi.Deployment.ConventionFailedException: Dynamic deployment failed
2013-11-04 17:41:29 +00:00 INFO   Login failed for user 'red_gate_deployment_manager'. ---> RedGate.Deploy.SqlServerDbPackage.Shared.Exceptions.SqlServerInaccessibleException: Dynamic deployment failed
2013-11-04 17:41:29 +00:00 INFO   Login failed for user 'red_gate_deployment_manager'. ---> System.Data.SqlClient.SqlException: Login failed for user 'red_gate_deployment_manager'.

我要部署的过程之一是指链接服务器上的分发数据库。定义如下所示：

CREATE PROCEDURE dbo.GetPublications
AS
BEGIN
  SELECT publisher_db, publication, description
  FROM DISTRIBUTOR.distribution.dbo.MSpublications;
END;

在 SSMS 中，我以 red_gate_deployment_manager 的身份连接到目标服务器并尝试手动创建该过程。我收到了类似的错误：

Msg 18456, Level 14, State 1, …