随着组织加速数字化转型之旅,有效管理数据的能力成为战略业务的当务之急。 随着人工智能驱动的应用程序和 Copilot 驱动的工作流程的兴起,企业正在以前所未有的速度生成和消费数据。 这些数据推动创新,提供个性化体验,并支持关键决策,但前提是要对其进行智能管理和存储。
为了支持这些不断变化的业务需要,公司必须采用主动的存储管理战略。 这可确保负责任地处理日常运营不再需要的数据,从而为高价值工作负载释放容量,减少运营摩擦,并符合合规性和审计要求。
从技术角度来看,Dynamics 365 中的 Dataverse 有效存储管理可增强系统性能、提高成本效率并确保遵守长期保留(LTR)策略。 这两个平台都提供工具和自动化功能,使组织能够管理存储。
通过实施本文中概述的战略,企业可以减少支持开销、简化法规遵从性并从其业务应用程序中释放更大的价值—将存储从限制转变为竞争优势。
关键优势
Dynamics 365 中的 Dataverse 有效存储管理提供了多项关键优势,可解决常见的客户痛点并提高整体运营效率。
提高 LTR 合规性:有效的存储管理可确保数据的存储符合 LTR 策略。 这不仅有助于满足监管要求,还可以确保关键数据在需要时得到保存和访问。
提高性能:通过优化存储管理,组织可以显着提高其系统的性能。 高效的存储分配和管理可减少延迟并提高数据检索速度,从而实现更流畅、更快速的作。
提高成本效率:有效的存储管理使组织能够通过简化和整理存储环境来专注于高价值数据。 通过仅保留必要的内容,企业可以优化其存储占用空间,从而实现更智能的资源利用率和经济高效的可扩展性。
背景
随着组织的发展和数字化更多的运营,存储在 Dynamics 365 等 Dataverse 系统中的业务数据量稳步增加。 这不仅包括活动事务数据,还包括必须保留用于审计、监管或业务连续性目的的历史记录。 随着时间的推移,这种积累会导致性能下降、运营开销增加和存储成本上升,尤其是当不再主动使用的数据仍保留在高性能存储层中时。
定义明确的存储管理战略通过识别可以存档、清理或移动到成本较低、读取优化的存储的数据,帮助公司应对这些挑战。 这对于数据必须保持不可变、低访问和只读的合规性方案(例如财务记录、审核日志或监管备案)非常重要。 确保以合规的方式保留此类数据,而不会影响实时系统的性能,是许多企业的关键要求。
通过使用这两个平台中可用的工具和策略,组织可以更好地了解其存储占用空间,减少不必要的消耗,并确保正确处理合规性关键数据。
本文概述了存储管理的实用方法,这些方法可帮助客户使其数据保留做法与业务和管理法规需要保持一致。 这提高了系统性能,减少了运营开销,并确保毫不妥协地履行合规性义务。
我们为什么存储数据
要为您的数据选择和优化正确的数据保留模式,反思我们存储数据的原因和用途非常重要。
运营数据
对于业务应用程序,运营数据用于跟踪销售或财务或供应链作。
需要实时访问这些数据,支持记录精细作的客户和内部运营流程,例如与客户的交互、订单或库存活动。
随着时间的推移,运营数据可能会从主动使用转变为不经常使用。 数据可能需要近乎实时地访问,以协助客户处理订单或处理支持案例。 例如,考虑以下情形:
- 一个客户下订单,而另一个已经有一段时间没有与企业互动的客户下订单。
- 每个已下达和正在发货的订单都会不断被访问。 还有一些保修期为三年的订单可能需要参考以获得支持,并且可能需要退款。
这可能会导致运营数据访问需求的阶段,例如:
- 主动访问的数据不到一年。
- 不到三年的不经常访问的数据。
- 超过三年,不再在作上访问数据。
与其他存储相比,作存储的实时性确实使其相对昂贵,因此识别何时需要在作中访问数据以及何时不需要访问数据对于定义保留策略非常重要。
运营集成
作为作用途的特殊类别,可能需要在多个作系统之间复制数据,包括以下模式:
- 银行业务:用于一线客户交互和复制到多个银行系统的客户关系管理。 例如,您有活期账户、信用卡、抵押贷款和信用检查系统。
- 制造业:用于一线接单的客户关系管理和用于供应链管理的企业资源管理系统。
- 警察紧急处理:公民互动的客户关系管理和警察部门的调度系统提供部署管理。
在这些情况下,虽然每个系统可能都有它跟踪的唯一数据,但通常有通用的主数据需要在系统之间共享并保持同步,从而导致集成需求。
审核数据
企业通常有监管责任将数据长期保留(例如平均七年)用于内部或外部审计目的,例如支持财务审计、监管披露或欺诈审查。
此数据通常涵盖作目的所需的数据和不再需要的数据,因为它允许从一个位置查看整个数据集。
分析数据
组织需要审查和分析其业务状况。 他们必须衡量和比较一段时间内的统计数据,并跨越业务的多个或所有部分。
这种分析可以处理大量数据,因此需要将运营数据复制到专门的分析工具中。 这避免了复杂的分析影响作系统的性能,而且还允许跨数据集进行分析,这些分析超出了作上需要数据的时间段。 例如,您可能需要比较七年的数据,而不是一到两年的数据。 但是,不同的分析需求可能需要完整的数据保留期,或者仅跨越作系统中保留的数据。
分析数据通常允许跨业务的多个部分聚合数据,并合并来自多个系统的数据。
数据流
这些类型的数据通常会随着时间的推移从作数据流向事务或历史数据,如下图所示。
不同类型的存储
Dataverse 存储类型
Dataverse 将存储分为三个主要类别,每个类别都有不同的使用模式和计费影响。
| 存储类型 | Description | 常见用例 |
|---|---|---|
| 数据库存储 | 将结构化数据存储在表中 - 标准表和自定义表。 | 业务记录、元数据、关系和配置 |
| 文件存储 | 存储附件和二进制数据。 | 通过上传的电子邮件附件、图像、文档 Power Apps |
| 日志存储 | 存储审计日志和插件跟踪日志。 | 更改跟踪、审核、诊断和合规性 |
财务和运营平台存储类型
财务和运营存储是单独管理的,但越来越多地集成到生态系统中 Power Platform 。 它包括以下存储类型。
| 存储类型 | Description | 常见用例 |
|---|---|---|
| 运营数据库存储 | 财务、供应链、人力资源等的核心事务数据 | 分类账分录、库存、客户订单 |
| 文档管理存储 | 存储在 Azure Blob 存储中的二进制大型对象(Blob) | 发票、收据、扫描文档 |
| 遥测和诊断日志 | 系统日志和遥测数据 | 性能监控,问题诊断。 |
共享和集成存储场景
双写存储
- 允许在财务和运营应用之间 Dataverse 进行实时同步。
- 需要仔细的角色和容量管理,以避免重复或过度使用。
长期保留(LTR)
- 将历史数据移动到托管数据湖(MDL)。
- 减少主存储使用量,同时保持合规性和分析访问。
- 集成:
- 快速查找(Dataverse- 本机搜索)
- OneLake(基于 Fabric 的分析)
- Synapse Link(自定义湖分析)
数据如何随时间增长
随着组织扩大对 Dynamics 365 财务和运营平台的 Dataverse 使用,数据增长既成为成功的标志,也成为战略挑战。 最初是一个精益的事务性数据集,可以迅速演变成一个复杂的多层数据资产。 本节探讨数据增长的五个关键驱动因素及其对存储、性能和治理的影响。
对运营数据使用数据仓库
为了从作系统中获取见解,许多组织使用 Azure Synapse Link、OneLake 或数据导出将财务和运营应用中 Dataverse 的数据复制到分析系统中。 虽然这支持高级报告和 AI 工作负载,但它还引入了:
跨作层和分析层的冗余存储
数据通常在作环境和分析环境之间重复。 这种冗余会增加总体存储消耗,并可能导致更高的成本,尤其是在两个系统中无限期保留历史数据时。
架构复制 和版本控制开销
为了保持系统之间的一致性,组织必须跨作层和分析层复制模式更改(例如,新字段和重命名的列)。 这增加了数据治理的复杂性,并增加了模式漂移的风险,这可能会破坏下游报告或模型。
增加趋势分析历史数据的保留
分析系统通常会将数据保留更长时间,以支持趋势分析、预测和监管报告。 虽然很有价值,但如果不使用适当的存档和分层策略进行管理,这种长期保留可能会导致数据集臃肿。
数据仓库对于分析至关重要,但如果没有生命周期策略,它可能会使您的存储占用空间增加一倍或三倍。
对数据使用搜索
搜索、Copilot 索引和相关性搜索等 Dataverse 功能需要为大量结构化和非结构化数据编制索引。 这些指数通常:
使用日志和数据库存储
搜索索引存储在日志和数据库存储中。 随着越来越多的表和字段被标记为可搜索,索引大小会成比例增长。 这会显着影响总体存储使用情况,特别是在具有大量记录或频繁更改模式的环境中。
即使对于未使用或已弃用的表,也可保留
即使某些表已弃用或不再主动使用,除非显式删除,否则其关联的搜索索引也可能保留。 这会导致不必要的存储消耗,并可能使容量规划复杂化。
通常在开发、测试和生产环境等环境中重复
搜索索引通常跨开发、测试和生产环境复制。 虽然这确保了一致的搜索行为,但它也会增加存储占用空间,尤其是在频繁克隆或刷新环境时。
搜索提高了可用性和 AI 就绪性,但索引膨胀是导致存储超额的一个无声因素。
启用数据日志记录
审核日志、插件跟踪日志和遥测对于合规性、调试和监视至关重要。 但是,请注意以下几点:
日志存储 随使用情况和用户数量线性增长。
日志数据按比例增长:
- 用户数量及其活动级别
- 交易量和集成量
- 业务逻辑(例如插件和工作流)的复杂性
在高使用率环境中,这可能会导致日志表快速扩展,从而消耗数据库和日志存储配额。
保留默认值 通常过于宽大,例如 90 天或更长时间。
默认情况下,许多日志记录功能会将数据保留较长时间,例如 90 天或更长时间。 虽然这支持长期可跟踪性,但它可能会导致不必要的存储消耗,尤其是在未主动查看或导出日志时。
系统生成的 日志将向客户 Dataverse计费。
在 Dataverse中,系统生成的日志(包括审核日志和插件跟踪日志)将计入客户的存储授权。 这意味着,如果没有适当的清理或导出策略,日志记录可能会直接导致存储超额和许可成本增加。
对于受监管的行业来说,日志记录是不可协商的,但必须与保留和导出策略(例如 Azure Monitor 或 Log Analytics)配对。
拥有生产环境的多个副本
为了支持开发、测试、培训和故障排除,客户通常会创建沙盒或克隆环境。 每个副本:
- 复制完整的数据和索引占用空间。
- 可能包括不明显的依赖项,例如搜索索引、审核日志和元数据。
- 使用后很少清理。
环境蔓延是存储成本和复杂性的主要驱动因素。 治理策略和自动化是遏制的关键。
优化对数据的查询
随着数据量的增长和应用程序响应能力变得至关重要,客户和 ISV 通常会实施各种查询优化技术来提高 Dynamics 365 中 Dataverse 的性能。 这些策略在报告、分析和集成密集型方案中尤为常见。
为了提高性能,客户和 ISV 通常会创建:
自定义索引和物化视图
这些用于通过预计算连接或聚合来加速查询执行。 它们在涉及复杂筛选器或大型数据集的方案中很有帮助。
用于报告的非规范化表
为了简化报告并降低查询复杂性,开发人员通常会创建关系数据的扁平化版本。 这些表减少了运行时联接的需求,并提高了仪表板性能。
缓存层或聚合
经常访问的数据有时会预先聚合或缓存在中间表或外部存储中,以减少主数据库的负载。
虽然这些提高了响应能力,但它们还:
增加存储使用量
每个优化层都会引入更多数据结构,无论是非规范化格式的现有数据副本、预计算视图还是缓存表。 这些结构通常会复制已存储在其他地方的数据,从而导致更大的整体存储占用空间。 在具有严格存储配额或基于成本的许可模式 Dataverse的环境中,这种情况可能会迅速升级为可避免的超额。
随着应用的发展,可能会成为孤立
随着应用程序的发展,活动报告、仪表板或集成可能不再引用某些优化工件。 如果 未识别和删除,这些孤立对象 会继续消耗存储,甚至可能会减慢系统作速度,例如在备份或索引期间。 如果没有定期审计,它们可能会在不被注意的情况下积累,从而破坏它们旨在支持的性能提升。
查询优化对于缩放至关重要,但必须与存储卫生和遥测驱动的优化相平衡。
索引及其对存储的影响
索引对于提高查询性能和在大型数据集中使用快速数据检索至关重要。 在 Dynamics 365 财务和运营应用中 Dataverse ,系统会自动为主键和经常查询的字段创建索引,并且可以定义其他自定义索引以支持特定的业务方案。
虽然索引对性能至关重要,但它们也会对存储消耗产生直接影响,而在解决方案设计过程中,这些消耗通常被低估。
索引如何使用存储
数据的物理重复:每个索引存储索引列的副本,以及指向相应行的指针。 索引的列和行越多,索引大小就越大。
随着数据量的增长:随着基础表的增长,索引也会随之增长。 在高事务环境中,索引可以快速增长,尤其是在大型非规范化表或频繁插入和更新的表上。
每个表有多个索引:单个表通常具有多个索引,例如用于搜索、筛选、排序和联接。 每个其他索引都会增加累积存储占用空间。
搜索索引: Dataverse搜索和 Copilot 索引等 Dataverse 功能创建跨多个字段和表的专用索引。 这些存储在 DataverseSearch 表中 ,可能会占用大量空间,尤其是在开发、测试和生产环境等多个环境中使用时。
系统生成的索引:某些索引由平台自动创建,例如查找字段或关系。 即使关联的表已被弃用,这些也可能持续存在,除非显式删除。
存储影响
- 增加数据库和日志存储:索引会影响数据库和日志存储的使用,这可能会影响许可 Dataverse成本。
- 环境复制:复制或刷新环境时,所有索引都会被复制,从而增加开发、测试和生产环境中的存储使用量。
- 维护开销:索引必须随着数据的变化而更新,这会增加写入延迟和资源消耗。
服务器端同步对存储的影响
服务器 Dataverse 端同步允许电子邮件、约会和任务 Microsoft Exchange Dataverse之间的无缝集成。 虽然它提高了生产力和自动化程度,但也通过以下方式增加了存储消耗。
- 活动记录创建:每个同步的电子邮件或约会都会生成一个活动记录 Dataverse,其中包括元数据、正文内容和潜在的附件。
- 附件存储:如果未过滤或卸载附件,它们将直接存储在其中 Dataverse,从而增加存储使用率。
- 合规性和保留:使用服务器端同步进行合规性跟踪的组织可能会保留比必要的更多的数据,从而进一步增加存储空间。
- 受保护的内容:即使是受 Purview 保护的电子邮件,尽管内容可见性有限,但仍会生成占用空间的占位符记录。
为了管理这种影响,企业应实施保留策略,考虑卸载附件,并定期监控活动记录量。
如何管理不断增长的存储?
无论您已经面临存储超额问题,还是希望保持领先地位,管理 Dynamics 365 财务和运营平台中 Dataverse 的数据增长都需要采用深思熟虑的、策略驱动的方法。 本部分概述了两个战略入口点:被动修正和主动治理。
有两种可能的情况:
- 您希望主动应用最佳做法来管理存储并避免将来的高成本。
- 您已经处于需要减少存储大小和成本的情况。
应用最佳做法来管理存储大小和成本
方案 1:您希望主动应用最佳做法来管理存储
如果您尚未处于危机模式,那么现在是时候应用工具和技术来主动管理存储了。
为数据配置分析
随着组织的发展,从运营数据中提取见解的需求也在不断增加,而不会影响核心业务应用程序的性能。 Microsoft 提供了多种方法,通过与您自己的数据湖或仓库集成,允许对 Dynamics 365 财务和运营数据进行 Dataverse 分析。
以下是两个值得考虑的强大选项:
选项 1。 使用 Azure Synapse Link–自带湖泊
Azure Synapse Link 允许你直接连接到 Dataverse 自己的 Azure Data Lake 或 Synapse 工作区。 这允许将运营数据近乎实时地复制到分析环境中,而无需编写复杂的 ETL 管道。
好处:
- 对实时或近实时数据运行高级分析和 AI 模型。
- 避免对生产系统的性能产生影响。
- 使用熟悉的工具,如 T-SQL、Spark 或 Power BI 用于报告。
用例示例: 一家零售公司使用 Synapse Link 跨区域分析客户购买行为,将客户关系管理数据与外部市场数据结合到 Dataverse 他们自己的湖中。
选项 2。 使用 OneLake–统一分析 Microsoft Fabric
OneLake 是其中 Microsoft Fabric的一部分,提供统一的数据湖体验,您可以在其中存储和分析来自多个源(包括 Dataverse 财务和运营应用)的数据,而不会重复。
好处:
- 适用于所有分析工作负载的集中存储。
- 与 Synapse 和 AI 服务的 Power BI本机集成。
- 简化跨数据域的治理和安全性。
用例示例: 一家金融服务公司使用 OneLake 整合来自财务和运营应用程序的运营数据以及 Dataverse 外部经济指标,从而实现实时风险建模和执行仪表板。 通过这样做,您可以将运营数据与核心系统分离,并通过将数据导出到他们自己的分析环境来实现可扩展、经济高效的分析,而不会重复工作负载或影响性能。
减少存储的工具和技术
Dataverse 提供了多种内置工具和策略来帮助管理员有效地管理存储并维护系统性能。
Dataverse
环境和数据清理
- 删除未使用的环境:可以删除环境以恢复存储空间并删除个人身份信息(PII)。
-
批量删除作业:可以批量删除以下数据:
- 过时的数据或与业务无关的数据。
- 不需要的测试数据或示例数据。
- 从其他系统错误导入的数据。
文件和表优化
- 使用高级查找减少文件存储空间:本文为您提供了 15 种方法来更好地管理存储空间。 使用这些方法中的一种或多种控制总数据存储使用情况。 您可以根据需要删除数据类别,或者设置批量删除作业以设定的时间间隔重复执行。 例如,您可以删除注释、附件、导入历史记录和其他数据。
- 清理系统作业(AsyncOperationBase)和进程日志(WorkflowLogBase)表中的记录:如果组织大量使用工作流或业务流程,则这些表(AsyncOperationBase、WorkflowLogBase)会随着时间的推移而增长,并最终变得足够大,以引入性能问题并消耗组织数据库中的过多存储。 对于 WorkflowLogBase,您可以配置为 自动删除已完成的后台工作流作业。
长期保留(LTR)和存档
- 数据存档:LTR: Dataverse 支持自定义保留策略,以经济高效的方式安全地长期保留无限数据。 虽然可以支持业务增长,但对活动数据没有限制,但 Dataverse 可能需要考虑将非活动数据移动到 Dataverse 长期保留存储。
- 清理 Dataverse 表:如果要保留数据,但将其从关系存储中删除,请转到 Dataverse 长期数据保留。 否则,请清理以下表:
- ActivityPointerBase:可以按照此处的步骤清理 表。
- AsyncOperationBase:可以按照此处 的步骤清理表。
- msdyn_copilotinteraction:您可以按照此处 的步骤清理表格。
- PrincipalObjectsAcces:可以按照此处 的步骤清理表。
- 订阅跟踪:您可以按照此处 的步骤清理表格。
搜索索引优化
- 减少 Dataverse 搜索:可以通过执行基于容量的存储详细信息 Dataverse 中的所有步骤来减小存储大小。
- 减小 DataverseSearch 表的大小: DataverseSearch 表是搜索索引使用的 Dataverse 累积存储。 它包括您为环境编制索引的表的所有可搜索、可检索和可筛选字段中的数据。 您可以通过删除一个或多个表的查找列、视图列和筛选条件来减小表大小。 您可以关闭 Dataverse 搜索来删除所有索引数据。
财务和运营应用
财务和运营应用提供了灵活的选项,用于跨生产和沙盒环境管理存储。
环境管理
- 限制完整生产副本的数量:您可以通过删除沙盒环境中的完整生产副本来减少财务和运营应用的总体存储消耗。 例如,如果沙盒中有五个生产环境副本,则存储消耗量是沙盒中生产环境的五个副本的总和。
- 在沙盒环境中修剪数据:通过在沙盒环境中修剪数据,可以减少总体存储占用空间。 您可以按照以下方法清理沙箱中的数据。
- 恢复过程提供打开和修剪执行
- 编写 T-SQL
- 编写 X++
- 在环境之间执行无事务复制:财务和运营应用的环境复制传统上涉及完整的数据库复制,包括配置、主数据和事务,这虽然对调试有用,但会显着增加财务和运营 Dataverse的存储消耗。
自定义清理和日志管理
- 根据需要编写自定义清理例程:您可以根据业务需要编写自定义清理例程来清理不需要的数据。
- 避免存储日志:可以将 SysDatabaseLog 移动 到事务性较低的数据库,以减少总体存储占用空间。
存档和长期保留
-
数据存档:LTR:财务和运营应用允许组织通过存档实现以下好处:
- 长期保护历史、非活动应用程序数据,以满足审计、法律和监管要求。
- 减小应用程序数据库的大小和消耗的容量,以潜在地提高与大型表关联的应用程序性能。
- 设置和管理存档数据
- 存档定制
- 库存交易合并
内置清理程序
- 清理例程:在 Dynamics 365 Finance 中, Dynamics 365 Supply Chain Management清理例程在各种模块中可用。 清理例程 概述了当前可用的例程。 复制沙盒数据库后,主动运行这些清理例程以删除不必要的表,例如批处理历史记录、日志和零售事务历史记录。 删除过时或不相关的数据。
- 存档信用卡交易数据:描述存档作业, Dynamics 365 Commerce 该作业可以通过存档信用卡支付令牌来帮助释放数据库中的空间。
减小存储大小和成本
方案 2:你已经处于需要减小存储大小和成本的情况
评估占用存储空间的内容
- 使用管理中心和财务和运营存储报表来 Power Platform 识别消耗最多的表、文件类型和日志。
- 使用遥测(如果可用)将使用情况归因于特定应用、用户或业务部门。
优先考虑清理候选者
- 重点:
- 暂存表和集成表,例如双写缓冲区
- 审核日志:将其保留在您自己的存储中
- 未使用的环境或沙箱
- 孤立的元数据和搜索索引
- 删除不需要的内容,例如批量删除
使用 Synapse Link 和 OneLake 进行分析报告
- 将分析数据导出到 Synapse Link。
- 使用 OneLake 访问保留的数据和业务数据,以进行报告和分析。
应用长期保留(LTR)
- 使用 LTR 策略将历史数据移动到托管数据湖(MDL)。
- 通过快速查找、Synapse Link 或 OneLake 维护搜索和分析访问权限。
用例
财务和运营环境中的存储管理 Dataverse 用例对于优化数据库空间、增强系统性能和满足法规要求至关重要。 以下是一些典型场景,演示了如何应用这些策略:
管理历史数据的增长
- 方案:一家企业已在 Dynamics 365 上上线数年,并积累了大量历史交易记录和附件。
- 作:实施长期保留策略以保留非活动数据、减小主数据库大小并保持对审计要求的合规性。
合规性驱动的数据保留
- 方案:受监管的行业客户必须以防篡改格式将财务或客户数据保留七到十年。
- 作:使用 LTR 保留不可变的只读数据,符合法律和法规要求,同时在不影响分析和报告的情况下保持业务数据精简。
搜索和 Copilot 索引优化
- 方案: Dataverse 搜索和 Copilot 索引在所有环境中启用,包括未使用的表。
- 作:审核可搜索字段并禁用低值表或已弃用表的索引。 监视 DataverseSearch 表的大小并优化配置以减少日志和数据库存储。
审计和遥测管理
- 方案:插件跟踪日志和审计日志正在快速增长,消耗存储并影响性能。
- 作:将日志导出到外部系统(如 Azure Monitor),并自动清理旧条目以保持可见性,而不会增加存储。
数据仓库和分析集成
- 方案:组织将作数据复制到 OneLake 或 Azure Synapse OneLake 进行分析,从而导致存储重复。
- 作:使用增量导出、应用筛选器并避免完整数据集复制,以最大程度地减少冗余,同时允许丰富的见解。
减少存储超额
- 场景:客户收到有关超出其 Dataverse 存储配额的通知,从而导致意外成本。
- 作:使用容量报告来识别消耗最多的表,清理过时的环境,并删除未使用的附件或日志。 考虑将冷数据(通常是历史记录或不经常访问的记录)移动到成本较低的存储层。
优化大型表的性能
- 方案:由于表过大,业务关键型流程速度变慢。
- 作:存档旧记录,清理系统作业,例如 AsyncOperationBase 和 WorkflowLogBase。
环境生命周期管理
- 方案:从生产中克隆开发和测试环境,复制所有数据和索引。
- 作:刷新后修剪沙盒环境,禁用不必要的搜索索引,并删除测试数据以减少冗余存储消耗。 删除未使用的沙盒环境以节省存储空间。
案例研究
案例研究 1:通过索引清理减少存储超额
客户资料:一家使用 Dynamics 365 进行供应链和财务和运营应用的全球制造公司。
挑战:客户在其生产环境中遇到了意外的存储超额和性能下降。 调查显示,在早期实施期间创建的多个自定义索引和物化视图已不再使用,但仍占用大量存储空间。
解决方案:该团队对所有自定义索引进行了季度审核,并删除了活动查询或报告未引用的索引。 他们还实施了治理策略,以在部署之前审查新的索引请求。
结果:
- 将数据库存储减少了 28%。
- 查询性能提高了 15%。
- 避免了其他存储成本的预计每年 $12,000。
案例研究 2:归档历史数据以满足合规性和绩效目标
客户配置文件:使用 Dataverse Dynamics 365 进行客户载入和案例管理功能的金融服务公司。
挑战:该公司需要将客户记录保留七年多才能满足监管要求,但不断增长的非活动数据量减慢了活动工作流程并增加了存储成本。
解决方案:客户使用存档功能实施 Dataverse了长期保留策略。 非活动记录被移动到只读、成本优化的存储层,而活动数据保留在高性能存储中。
结果:
- 存档超过 120 万条记录。
- 将主数据库大小减少了 40%。
- 保持完全的可审计性并遵守保留策略。
案例研究 3:简化跨环境的搜索索引
客户资料:具有多个 Dataverse 环境(包括开发、测试和生产环境)的零售组织,支持支持 Copilot 的客户关系管理解决方案。
挑战:搜索索引在所有环境中都使用,包括未使用的表和测试数据。 这导致 DataverseSearch 表臃 肿和不必要的存储消耗。
解决方案:团队审查了可搜索字段,并停止在开发和测试环境中对非关键表使用索引。 它们还在环境刷新期间自动清理索引。
结果:
- 搜索索引存储减少 35%。
- 将环境刷新时间缩短了 20%。
- 降低了日志和数据库存储的总体使用量。
案例研究 4:使用数据导出进行分析,无需重复存储
客户配置文件:使用 Dynamics 365 并 Dataverse 用于患者参与和计费的 healthcare 提供商。
挑战:分析团队需要访问运营数据以进行趋势分析和 AI 建模,但将数据复制到单独的仓库中会增加存储成本和复杂性。
解决方案:客户在OneLake 中使用了具有 Azure Synapse 增量导出和分层存储功能的 Link。 他们只保留必要的分析数据,并应用保留策略来管理历史深度。
结果:
- 在不影响作系统的情况下实现实时分析。
- 冗余存储减少了 45%。
- 改进了对分析数据生命周期的治理。
结束语
有效的存储管理对于维护 Dynamics 365 环境中的系统性能和优化资源利用率至关重要。 本文中概述的清理例程和存档作业提供了强大的解决方案,以释放宝贵的数据库空间并简化作。 通过使用 LTR 和类似技术等这些工具,客户可以解决常见的存储挑战并创建可持续的数据管理实践。 此外,现实世界的案例研究证明了这些方法的有效性,为其实际应用提供了见解。 采用这些策略使组织能够主动管理其存储需求并提高整体效率。
引用
存储清理: Dataverse
财务和运营中的存储清理:
- 财务和运营存储容量
- 清理 Dynamics 365 Finance 和 Dynamics 365 Supply Chain Management 中的例程
- 存档信用卡交易记录数据 - Commerce
存储容量: