标签: datafile

我有一个大型（1.2 TB）SQL Server 数据库，需要将其迁移到新服务器。大部分数据库位于一个 1.25 TB 的数据文件中，还有一小部分位于更易于管理的 550 GB 文件（实际上是空的）上。

现在，棘手的一点是：我要迁移到的服务器只有 3 700 GB 的卷，这意味着我需要以某种方式将这个巨人分解成三个相等的块。我发现的大多数建议涉及创建 3 个目标文件并在我的主文件上运行 DBCC SHRINKFILE EMPTYFILE 以将其清空到目标中，但是对于这么大的数据库，这需要很长时间。

有没有推荐的方法来拆分这么大的数据库？我正在考虑使用 Sql Server 集成服务数据导出功能将数据转储到具有正确文件结构的克隆数据库中，但我很好奇是否有更好的方法。

我想知道为什么我们要在 /var/lib/mysql/ 下部署数据文件。这是否有合乎逻辑的原因，或者这只是数据的“传统”位置？

我将重视基于 LSB 或 POSIX 等标准的更多答案，并希望链接到您最喜欢的 Linux 或 Unix 实现的政策，这些政策规定这是部署数据的预期位置。

非常感谢您的关注和回答。

亲切的问候，

-- LMC

只是想知道如果我用 索引了一个表，索引信息在 MySQL 数据库中的物理位置在ALTER TABLE contacts ADD KEY (columnName);哪里？

1. 它将留在该表中并为其添加一个新的空间列；
2. 与那张桌子分开；

我认为 #2 是正确的答案。

我们可以索引多个表中的列吗？如何？

我在 SQL Server 2008 R2 上有一个包含 5 个 .ndf（辅助）数据文件的数据库。（这些数据文件中的每一个都被分配到一个单独的文件组。）我想知道这些文件中有哪些数据。是否可以？我知道这些文件组中有全文索引（并且由于每个文件组只有一个文件，因此创建这么多文件的唯一目的可能是将全文索引放在不同的文件组中，我不知道）。我想确保除了全文索引之外没有其他数据。
谢谢

TL\DR

我正在寻找一种方法来有效地识别最靠近物体结束一个的SQL Server的数据文件。这种方法需要对大型数据文件保持高性能。

到目前为止我所拥有的

下面的查询使用一个未公开的动态管理功能是随2012 SQL：sys.dm_db_database_page_allocations; 此 DMF 提供了与DBCC IND命令的粗略等效项。

以下查询标识给定数据文件中的最后一个对象（警告：不要对大于 25 GB 的数据库运行此查询，除非您想在某个时候取消它）：

-- Return object with highest Extent Page ID
SELECT   files.name as logical_file_name
        , files.physical_name as physical_file_name
        , OBJECT_SCHEMA_NAME(object_id) + N'.' + OBJECT_NAME(object_id) AS object_name
        , alloc.*
FROM sys.dm_db_database_page_allocations(DB_ID(), NULL, NULL, NULL, NULL) alloc
    INNER JOIN sys.database_files files
        ON alloc.extent_file_id = files.file_id
WHERE is_allocated = 1
    AND files.name = 'Logical_FileName'
ORDER BY files.name , files.physical_name, …

我正在尝试从未使用的文件组中删除数据库中的所有文件。有两个文件总共约 1.5TB。我可以看到这些文件中现在还有大约 400mb，但我看不到它是什么或如何删除它。

select * from sys.allocation_units a --where data_space_id = 6
inner join sys.partitions b on a.container_id = b.hobt_id --type = 1
where data_space_id = 6

--给了我以下结果集

SELECT * INTO #tmp_GridResults_1
FROM (
SELECT N'72057781944647680' AS [allocation_unit_id], N'1' AS [type], N'IN_ROW_DATA' AS [type_desc], N'72057777021059072' AS [container_id], N'6' AS [data_space_id], N'0' AS [total_pages], N'0' AS [used_pages], N'0' AS [data_pages], N'72057777021059072' AS [partition_id], N'741132535' AS [object_id], N'9' AS [index_id], N'1' AS [partition_number], N'72057777021059072' AS [hobt_id], N'0' AS [rows], N'0' AS [filestream_filegroup_id], …

我有一个example.mdf总大小为 1GB的数据库，它存在性能问题。我检查了分配的硬件，它高于要求，我仔细检查了设计，一切看起来都正常，当我查看.mdf物理位置 ( C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\example.mdf)中的文件时，我发现数据库被拆分为多个文件example_1.mdf, example_2.mdf, example_3.mdf, 直到example_7.mdf.

我在同一 SQL Server 上有另一个具有相同问题的数据库文件。

为什么会发生这种情况？这会影响性能吗？如何防止或阻止 SQL Server 拆分我的.mdf文件？此外，我需要合并回已经拆分的文件。

我需要一个将以下结果放在一起的查询：

• 跨所有数据库的每个数据库文件一行
• 包含有关文件所在的本地驱动器的信息的附加列
• 有关文件大小和用途的信息

到目前为止，我已经整理了以下查询：

    SELECT 
     GETDATE() as dt
     ,@@SERVERNAME as srv
     ,F.name 
     ,F.physical_name    
     ,Round(F.size * 8 / 1024, 2) as FileSizeMb
    , CAST(FILEPROPERTY(F.name, 'SpaceUsed') AS INT)/128 as FileUsedMB
    ,(F.size/128 - CAST(FILEPROPERTY(F.name, 'SpaceUsed') AS INT)/128) AS FileFreeMB
    ,Convert(decimal(18,2), (F.size/128 - CAST(FILEPROPERTY(F.name, 'SpaceUsed') AS INT)/128) / (F.size * 8 / 1024.1) * 100) as SpaceFreePerc 
     ,stat.size_on_disk_bytes / 1024 / 1024 SizeOnDiskMb
     ,drv.volume_mount_point, drv.logical_volume_name, drv.available_bytes, drv.total_bytes 
 FROM sys.master_files F 
 inner join sys.dm_io_virtual_file_stats(NULL, NULL) stat on F.database_id = stat.database_id AND F.file_id = stat.file_id …

我们有一个 120GB 的数据库。有一个包含 60GB 数据的表，这是无用的，我们已经截断了它。

现在数据库大小为 120GB，可用空间为 60GB。数据库至少在 3 个月内不会增长到 60GB。所以我们可以缩小数据文件。

我知道碎片问题。我可以重建我的索引，因为我们的不是 24*7 的数据库。

请建议缩小MDF文件

我有一个奇怪的情况，我有一个生产数据库和一个还原副本作为同一个 SQL Server 实例上的另一个数据库，并且它们都使用相同的 MDF 和 LDF 文件（即它们在 SQL Server 中具有相同的“逻辑”文件管理工作室）。从我在研究时发现的情况来看，这是可能的，但所有迹象都表明它们都指向相同的数据，这是一个合理的假设。

但是，就我而言，两个数据库实际上包含不同的数据。如果我对两个同名表（每个数据库中一个）运行 select 语句，它们将返回不同的数据。我已经双重、三重和四重验证了这一点。这怎么可能？MS 文档或我发现的任何内容都没有谈到共享相同 MDF 文件但具有不同数据的两个数据库。

不涉及NDF文件，每个DB有一个文件组，每个文件组只有一个文件。