一个文件组可以被多个数据库使用

Posted 2023-05-02

　　1、一个文件或文件组不能由多个数据库使用。例如，任何其他数据库都不能使用包含 sales 数据库中的数据和对象的文件 sales.mdf 和 sales.ndf。

　　2、一个文件只能是一个文件组的成员。

　　3、一个文件组可以包含多个文件，一个数据表在创建时可以指定要将数据放在那一个文件组上，而没有办法指定是要放在哪一个文件上，文件组对组内的所有文件都使用按比例填充策略。

　　4、事务日志文件不能属于任何文件组。

使用文件和文件组时的一些一般建议：

大多数数据库在只有单个数据文件和单个事务日志文件的情况下性能良好。

如果使用多个文件，请为附加文件创建第二个文件组，并将其设置为默认文件组。这样，主文件将只包含系统表和对象。

若要使性能最大化，请在尽可能多的不同的可用本地物理磁盘上创建文件或文件组。将争夺空间最激烈的对象置于不同的文件组中。

使用文件组将对象放置在特定的物理磁盘上。

将在同一联接查询中使用的不同表置于不同的文件组中。由于采用并行磁盘 I/O 对联接数据进行搜索，所以性能将得以改善。

将最常访问的表和属于这些表的非聚集索引置于不同的文件组中。如果文件位于不同的物理磁盘上，由于采用并行 I/O，所以性能将得以改善。

请勿将事务日志文件置于其中已有其他文件和文件组的物理磁盘上。

文件组对组内的所有文件都使用按比例填充策略的解析：

当数据写入文件组时，SQL Server 数据库引擎按文件中的可用空间比例将数据写入文件组中的每个文件，而不是将所有数据都写入第一个文件直至其变满为止。然后再写入下一个文件。例如，如果文件 f1 有 100 MB 可用空间，文件 f2 有 200 MB 可用空间，则从文件 f1 中分配一个区，从文件 f2 中分配两个区，依此类推。这样，两个文件几乎同时填满，并且可获得简单的条带化。

假定将数据库设置为自动增长，则当文件组中的所有文件填满后，数据库引擎便会采用循环方式一次自动扩展一个文件以容纳更多数据。例如，某个文件组由三个文件组成，它们都设置为自动增长。当文件组中所有文件的空间都已用完时，只扩展第一个文件。当第一个文件已满，无法再向文件组中写入更多数据时，将扩展第二个文件。当第二个文件已满，无法再向文件组中写入更多数据时，将扩展第三个文件。当第三个文件已满，无法再向文件组中写入更多数据时，将再次扩展第一个文件，依此类推

自己实践过程摸索的内容：

　　文件与文件组的删除，如果因为以前的分区方案不合理，需要取消分区，或者按另外一种方式分区，就需要涉及到文件与文件组的删除操作，如果没有掌握正确步骤，有时候可能无法删除，会提示你“文件不为空，无法删除”或者“文件组不为空，不能删除”等等，如果不知道技巧，会很郁闷！本人就曾经经历过这样的郁闷！在百度也没找到正确答案，下面说说我自己经过摸索后得到的答案。

1、 文件的删除：首先要先清空文件里的数据，删除之前数据一定要记得先备份，可将数据复制到其他表，然后执行：

DBCC SHRINKFILE (FileName, EMPTYFILE);
文件中的内容删除后，再执行删除文件命令，DataBaseName表示数据名，FileName 表示文件名：

ALTER DATABASE [DataBaseName] REMOVE FILE FileName;
2、文件组的删除：

当文件组的文件被删除后，按正常理解，应该就可以直接删除文件组，实际是不行的，你无法删除文件组。

因为还有几个东西依赖文件组，一是分区方案，二是使用该分区方案的分区表。

所以要删除分区方案才能删除文件组。但要删除分区方案之前要先更改依赖它的分区表，使其不依赖它。

这个主要是更改分区表的分区列，使其不使用分区方案，如果实在不会更改，在表里数据已经备份的前提下，可以直接删除表来解决。

　　然后再删除分区表方案，最后就可以直接删除文件组了。

总结前面的删除过程：

1、修改分区表，使其不依赖分区方案。

　2、删除分区方案（依赖要删除的文件组）。

DROP PARTITION SCHEME [Part_func_scheme_Name]
　3、直接删除文件组。

ALTER DATABASE [DataBaseName] REMOVE FILEGROUP [FGName]
DataBaseName表示数据名，FGName 表示文件组名。 参考技术A 不可以
1.数据文件：存放数据库数据和数据仓库对象的文件

主要数据文件（.mdf）+次要数据文件（.ndf）

主要数据文件只能有一个，存放数据库的启动信息和数据，次要文件存放主数据文件存放不下的数据

2.事务日志文件：用于恢复数据库的日志信息，扩展名为.ldf

当数据库破坏时可以用事务日志还原数据库内容

可以一个或多个

3.文件组是将多个数据文件集合起来形成的一个整体

主要文件组+次要文件组

一个数据文件只能存在与一个文件组中

一个文件组也只能被一个数据库使用

日志文件不分组，不属于任何文件组 参考技术B 不可以
一个文件组也只能被一个数据库使用 日志文件不分组,不属于任何文件组 创建数据库 CREATE DATABASE 数据库名称 ON [FILEGROUP 文件组名称] 参考技术C 一个文件或文件组不能由多个数据库使用。例如,任何其他数据库都不能使用包含sales数据库中的数据和对象的文件sales.mdf和sales.ndf。 参考技术D 一个文件组也只能被一个数据库使用
日志文件不分组,不属于任何文件组 创建数据库 CREATE DATABASE 数据库名称 ON [FILEGROUP

RocketMQ

消费流程

消费者组： 一个逻辑概念，在使用消费者时需要指定一个组名。一个消费者组可以订阅多个Topic。
消费者实例： 一个消费者组程序部署了多个进程，每个进程都可以称为一个消费者实例。
订阅关系： 一个消费者组订阅一个 Topic 的某一个 Tag，这种记录被称为订阅关系。RocketMQ规定消费订阅关系（消费者组名-Topic-Tag）必须一致——在此，笔者想提醒读者，一定要重视这个问题，一个消费者组中的实例订阅的Topic和Tag必须完全一致，否则就是订阅关系不一致。订阅关系不一致会导致消费消息紊乱。

消费模式

RocketMQ目前支持集群消费模式和广播消费模式，其中集群消费模式使用最为广泛

集群消费模式

在同一个消费者组中的消费者实例，是负载均衡（策略可以配置）地消费Topic中的消息，假如有一个生产者（Producer）发送了 120 条消息，其所属的 Topic 有 3 个消费者（Consumer）组，每个消费者组设置为集群消费，分别有2个消费者实例，如图所示。

Consumer Group A 的两个实例 Consumer Instance A1 和 Consumer Instance A2 分别负载均衡地消费60条消息。由此我们可以得出使用负载均衡策略时，每个消费者实例消费消息数=生产消息数/消费者实例数，在本例中是60=120/2

适用场景： 目前大部分场景都适合集群消费模式，RocketMQ 的消费模式默认是集群消费。比如异步通信、削峰等对消息没有顺序要求的场景都适合集群消费。因为集群模式的消费进度是保存在Broker端的，所以即使应用崩溃，消费进度也不会出错。

广播消费模式

广播消费，顾名思义全部的消息都是广播分发，即消费者组中的全部消费者实例将消费整个 Topic 的全部消息。比如，有一个生产者生产了 120 条消息，其所属的 Topic 有 3个消费者组，每个消费者组设置为广播消费，分别有两个消费者实例，如图所示。

Consumer Group A 的两个实例 Consumer Instance A1 和 Consumer Instance A2 分别消费120条消息。整个消费者组收到消息120×2=240条。由此我们可以得出广播消费时，每个消费者实例的消费消息数=生产者生产的消息数，整个消费者组中所有实例消费消息数=每个消费者实例消费消息数×消
费者实例数，本例中是240=120×2

适用场景： 广播消费比较适合各个消费者实例都需要通知的场景，比如刷新应用服务器中的缓存，如图所示。

生产者发一个刷新缓存的广播消息，消费者组如果设置为广播消费，那么每个应用服务中的消费者都可以消费这个消息，也都能刷新缓存。

广播消费的消费进度保存在客户端机器的文件中。如果文件弄丢了，那么消费进度就丢失了，可能会导致部分消息没有消费

可靠消费

RocketMQ是一种十分可靠的消息队列中间件，消费侧通过重试-死信机制、Rebalance机制等多种机制保证消费的可靠性。

重试-死信机制

我们假设有一个场景，在消费消息时由于网络不稳定导致一条消息消费失败。此时是让生产者重新手动发消息呢，还是自己做数据补偿？

横向看，RocketMQ的消费过程分为 3个阶段：正常消费、重试消费和死信。在引进了正常Topic、重试队列、死信队列后，消费过程的可靠性提高了。RocketMQ的消费流程如图所示

正常Topic： 正常消费者订阅的Topic名字。
重试Topic： 如果由于各种意外导致消息消费失败，那么该消息会自动被保存到重试Topic中，格式为“%RETRY%消费者组”，在订阅的时候会自动订阅这个重试Topic。

进入重试队列的消息有16次重试机会，每次都会按照一定的时间间隔进行。RocketMQ 认为消费不是一锤子买卖，可能由于各种偶然因素导致正常消费失败，只要正常消费或者重试消费中有一次消费成功，就算消费成功

死信Topic： 死信Topic名字格式为“%DLQ%消费者组名”。如果正常消费1次失败，重试16次失败，那么消息会被保存到死信Topic中，进入死信Topic的消息不能被再次消费。RocketMQ认为，如果17次机会都失败了，说明生产者发送消息的格式发生了变化，或者消费服务出现了问题，需要人工介入处理。

Rebalance机制

Rebalance（重平衡）机制，用于在发生Broker掉线、Topic扩容和缩容、消费者扩容和缩容等变化时，自动感知并调整自身消费，以尽量减少甚至避免消息没有被消费。后面会详细讲述Rebalance的过程。

死信队列

当一条消息初次消费失败，消息队列RocketMQ版会自动进行消息重试，达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息。此时，消息队列RocketMQ版不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

在消息队列RocketMQ版中，这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）

死信消息具有以下特性：

• 不会再被消费者正常消费。
• 有效期与正常消息相同，默认为3天，3天后会被自动删除。因此，请在死信消息产生后的3天内及时处理。

死信队列具有以下特性：

• 一个死信队列对应一个Group ID， 而不是对应单个消费者实例。
• 如果一个Group ID未产生死信消息，消息队列RocketMQ版不会为其创建相应的死信队列。
• 一个死信队列包含了对应Group ID产生的所有死信消息，不论该消息属于哪个Topic。