很多人，可能大多数人都熟悉SAP HANA的多租户数据库概念。顾名思义，它允许在逻辑上隔离的数据库中分离租户数据，这些数据库再次在单个裸机系统上运行，大数据推荐，并共享相同的低级别（操作系统和特定于基础结构的）资源（内存、CPU功率、存储等）。这个概念使HANA成为一个云就绪的数据库；它特别支持租户数据库的弹性部署和操作。例如，客户（租户）可以为其云帐户请求一个HANA数据库实例，并将在该帐户中获得一个"租户"数据库。这些租户对坐在一起的其他租户是不可知的，即使是在同一个主机上。我了解一些系统，它们通过在数据库表中设置属性甚至标志来实现数据库目录中的这种隔离。在HANA中，隔离级别要低得多；HANA租户有单独的目录、存储库、用户保险库等。但有时您可能希望显式访问租户数据库，而不是显式拥有的数据库！我们最近在一个项目中有这个要求。在开发系统中产生了大量的数据，淘客文案，但是过了一段时间之后，我们需要将数据移动到QA实例中。我们可以用传统的方法来解决这个问题："从DEV导出数据并在QA中导入它们"。但这意味着我们要在中间步骤中存储GBs的数据。我们希望避免这种情况，因为我们对存储基础架构有一些限制。因此，我们决定配置跨租户数据库访问，只需从原始表中"SQL select"数据，然后将它们"SQL insert"到新租户的表中。而这一努力却变得相对较低！
在下面，我将以一种端到端的方式来描述这个过程，甚至用实际的表、模式和用户为例。您将能够在本地HANA实例（例如HANA Express）上重现此过程。这在云中不起作用，因为云帐户不能访问云实例的"系统数据库"（云帐户总是获得租户实例）。在执行配置和执行（SQL）代码时，我使用了SAP HANA 2.0 SPS02。
注意：我在这里介绍的所有内容都可以在有关HANA的官方文档中找到。信息分散，但可用。我在这里做的唯一不同之处是，在一个步骤中，官方文档要求使用HANA驾驶舱。我忽略了那个"推荐"，只是在我的HANA工作室里完成了这个步骤。
注意：社区里已经有其他关于这个主题的博客了。举个例子来说。当我开始写这些行时，它是我的项目团队同事的一个文档。后来我们意识到，社区中有可用的信息（例如，我刚才提到的博客），购返利，但我的团队鼓励我以博客的形式发布信息——不管关于这个主题的信息已经存在的事实。我希望，大数据和数据库，您会发现它很有用。
注意：从HANA 2.0 SP01开始，HANA只作为所谓的多租户数据库安装。这意味着，
系统数据库和租户数据库
系统数据库（每个SID只有一个）负责保存整个数据库实例的系统设置和配置。这不是一个完整的SQL数据库，不应（也不能）用于存储应用程序数据。
应用程序数据存储在租户数据库中。默认情况下安装一个租户数据库。这个"默认"租户数据库的名称等于SID，例如HA1。此外，还可以代表项目创建任意多个租户数据库。
我的HANA实例的SID是HA1–每个安装。我自动获得了一个与SID同名的租户实例。然后，我通过在HANA Studio中执行以下命令（作为系统数据库中的用户系统）创建了第二个租户数据库。
此命令还设置租户数据库HA2中用户系统的密码。我最终得到了一个系统数据库（HA1）和两个租户数据库（HA1和HA2）。
在所有数据库（system和tenant）中都有用户系统。但随后我还在租户数据库中创建了"开发人员用户"（分别是GORANHA1和GORANHA2）。我还在各自的租户数据库中创建了这些用户所拥有的模式（由用户系统执行）：
然后我需要一些表（或者至少一个表，以便能够在这个博客中循环使用）。我在两个模式中创建了表填充。以下是它在HA1中的定义：
注意：在实际项目中，这些类型的用户和模式很可能已经存在。您可能需要调整权限，以便能够在相应的架构和表中执行选择和插入。这也适用于由HDI容器从webide生成的用户和模式！这里我列出了运行时对象的概念，但它们也适用于设计时工件。
结果如下（仅作概述）：
系统数据库HA1
租户数据库HA1
Schema=DENMARK所有者=GORANHA1表=人口
租户数据库HA2
模式=挪威所有者=GORANHA2Table=POPULATION
这是我的HANA工作室中的连接的样子：
启用访问相对容易。首先对相应的数据库启用系统数据库级的交叉访问。访问是单向的。只需在HANA Studio的user system中对系统数据库发出命令：
这些命令告诉系统数据库租户HA2想要访问租户HA1。这将导致全局.ini系统数据库：
