关于DB In-Memory Option你必须知道的17个问题

Oracle数据库内存(Oracle Database In-Memory)选件于美国时间610日发布。根据甲骨文中国的报道,选件进一步增强了Oracle数据库12c的威力,而且可以透明运行,使企业能够实时发现深度商业信息,提高交易性能。凭借Oracle数据库内存选件,用户可以即刻得到业务问题的答案,这在以前则需要数小时时间。此外,用户还能够为内部及外部人员提供更快、更好的体验。


下面是云和恩墨专家张乐奕第一时间对于选件的
17个重点解析:

1Oracle Database In-Memory选件什么时候能够发布?
该选件将包含在Oracle Database 12c的第一个Pacthset12.1.0.2)中一起发布。


2
、价格如何?

价格会在发布日的时候决定。


3
、新的Oracle Database In-Memory选件是否会替代In-MemoryDatabase Cache(就是TimesTen技术)选件?

当然不,完全不一样的应用场景。In-Memory Database Cache是在应用程序层通过TimesTen来管理的内存性质的数据库,这是为了让OLTP应用享受到对于存储在Oracle数据库中一部分表的超低延迟访问而设计的。


4
Oracle Database In-Memory选件是否会替代TimesTen

当然不。像上面所说,TimesTen通常是部署在应用层的,可能是作为一个独立的数据库,也可能是作为在Oracle数据库前面的In-Memory Database CacheTimesTen提供的是超低延迟数据访问,由此提供了极速的响应时间。由此受益的OLTP系统通常不会创建用于报表应用的索引,也因此通常无法从数据库层的Oracle Database In-Memory选件中获得多少性能提升。


5
Oracle Database In-Memory选件是否会替代Exalytics

当然不。并不是所有客户都需要在他们的系统中拥有强力的分析能力,而ExalyticsOracle的一体化策略分析平台。它提供了丰富的分析工具和可视化工具,以及大量的标准报表、预测分析、数据发现,是为了最优化地运行BIEPM工作的平台,是对数据库层的补充而不是竞争。 Exalytics也不仅仅是针对Oracle Database 12c的,它可以处理多种数据源,包括TeradataOracle database 11gSAP Netweaver等。


6
、那么在Exalytics中使用的是什么关系型内存数据库引擎呢?

Exalytics使用的是TimesTen In-MemoryDatabase for Exalytics。在TimesTen产品发展路线图中也包含着跟Oracle Database In-Memory选件相类似的列式存储技术,而且是使用的相同的底层列式处理架构。这项技术计划在2014年跟Oracle Database In-Memory选件一起在相同的时间窗口发布。实际上,TimesTenOracleDatabaseIn-Memory选件在Oracle公司内部是由同一个小组来开发的,共享相同的创新技术以及底层架构。


7
、那么在Exalytics中使用的内存数据库引擎在未来会变成Oracle Database In-Memory选件吗?

没有这个计划。Oracle期望TimesTen会持续研发。


8
Oracle Database In-Memory选件是否会替代Exadata

当然不。这个问题太幼稚,就不做解释了。


9
、好吧,那到底什么是Oracle Database In-Memory选件呢?

这是一项新的技术,内置在Oracle数据库中,通过内存中的列式存储数据来获得超快的数据处理能力。


10
、当使用Oracle Database In-Memory时,数据库的大小受限于服务器中的可用内存容量吗?

不。由用户来决定哪些对象会存在In-Memory列式缓存中。如果一张表太大了,无法完全缓存在In-Memory列存中,Oracle会尝试将尽可能多的数据保持在内存中(以列的形式),剩下的仍然存储在闪存或者磁盘中(以原来行的形式),这样的操作非常高效并且是完全透明的。你可以有选择性的定义一部分数据库,比如将热表、热分区、经常访问的列放入内存中。这就让除了Oracle原有的那些跨越内存、闪存、磁盘的各种优化方式之外,Oracle Database In-Memory选件还能够专门为频繁访问的业务关键数据提供帮助。当然,如果数据库足够小,全部表都能使用Oracle Database In-Memory选件。


11
Oracle Database In-Memory选件只会对分析/报表类业务有帮助吗?

虽然确实分析/报表类业务能够从列式存储中获得最多的收益,但是其他类型业务也同样能够受益。比如通过减少需要的索引,就能够加速OLTP业务。通常在以前的混合负载业务中需要在表上创建很多的多字段索引来支撑报表类型的查询,如今In-Memory列存则对DML操作造成更少的影响,而又可以提供相同的查询性能。减少索引还能够带来优化和管理的简便,DBA不再需要去rebuild那些碎片化的索引,也不再需要去研究为什么优化器选择了错误的索引。


12
、从Oracle Database In-Memory功能中能够期望获得多少性能提升?

使用该选项能够为多种查询负载提供显著的性能提升。从一个非常简单的星型查询到一个非常复杂的具有多个子查询的SQL,就算所有的的表都在内存中,In-Memory列式缓存仍然会胜过普通的Buffer Cache。比如说,In-Memory列存在查询很少列上的很多行时,会提供极高的性能,通常这类查询都是分析类的查询,在这类查询上使用In-Memory列存和使用普通缓存(Buffer Cache)相比,有超过100倍的性能提升。


13
、当使用Oracle Database In-Memory选件的时候,我该对索引做些什么吗?

你可以保留以前的所有索引,就像以前那样运行你的应用。Oracle优化器完全能够感知到内存中的列式数据,只有当确认使用这些列式数据会有性能提升的时候才会使用到,如果优化器认为从索引访问中能够获得更好的性能,那么就会自动去读取普通缓存(Buffer Cache)中的数据,就跟以前一样。不过,如果将一些多列索引设置为invisible,引导Oracle优化器更多地去选择列式缓存,可能会带来额外的速度提升。然后,你可以删除掉这些无用的索引,这样又能带来进一步的性能提升,因为Oracle数据库需要维护的索引更少了。


14
、如果使用Oracle Database In-Memory选项,数据库现在的功能会受影响吗?

没有任何一项现有的Oracle数据库功能会受到Oracle Database In-Memory选项的限制;很多操作还能在性能上获得显著提升;一些原本为了提高性能所做的操作(比如创建索引)会变得不再重要;安全性、高可用性以及其它的所有功能都跟以前一模一样,完全不受影响。当然在DML操作上会有一些额外消耗,因为In-Memory列存要时刻跟表数据保持同步,但是这部分列存是完全在内存中的,所以不需要额外的Logging操作。


15
Oracle Database In-Memory选项在高可用性上跟其它厂商的内存数据库相比如何?

因为In-Memory列存并没有给Oracle数据库施加任何限制,因此在高可用性上可以享受Oracle数据库完整的丰富的高可用解决方案,而其它厂商的高可用性均不太完备。


16
、如何规划In-Memory列存所需要的内存大小?

In-Memory Area(用于保存In-Memory列存的内存区域)是SGA中的一块新的缓存池,该缓存大小由初始化参数INMEMORY_SIZE指定,如果一旦设定,最小是100MB。因为In-Memory AreaSGA的一部分,因此其最大大小受制于分配了其它所有内存池之后的SGA中的剩余空间。INMEMORY_SIZE默认是0,也就是不启用Oracle Database In-Memory选项。 由于In-Memory Area是一块静态区域,所以不会被自动内存管理算法所影响。 如果想要修改In-MemoryArea的大小,需要重启数据库实例,在RAC数据库中,可以在各实例的内存中复制In-Memory列存,因此可以通过重启节点的方式来最小化对应用的影响。


17
、在RAC环境中,是否In-Memory列存是在集群的所有节点中完全镜像的?

RAC环境中,用户可以自行设定使用以下三种选项中的任何一种: 1. 在所有实例的内存中镜像相同的表数据。这样每个实例都会读取自己的本地内存,通常这用于较小的表。 2. 表数据分布在所有实例的内存中。这样每个实例内存中只会保存表中的一部分数据,没有冗余复制。 3. 表数据分布在所有实例的内存中,并且为高可用性保留2份镜像。这种工作机制很像ASM的条带化和冗余性。

<think>好的,我现在需要解决Memurai无法保存RDB快照的问题,同时启用磁盘持久化,并修复stop-writes-on-bgsave-error导致的写入错误。首先,我应该回顾一下用户的需求:他们遇到了RDB快照失败,触发了stop-writes-on-bgsave-error配置项,导致写入被阻止。用户希望解决这个问题,确保持久化正常工作。 首先,我需要确认Memurai的配置是否与Redis类似,因为Memurai是基于Windows的Redis兼容版本。Redis中,当启用了RDB持久化,如果后台保存失败,stop-writes-on-bgsave-error选项会决定是否停止接受写操作。默认情况下,这个选项是开启的,所以一旦bgsave失败,就会拒绝写入。 接下来,可能的故障点包括: 1. **权限问题**:Memurai是否有足够的权限写入指定的目录?需要检查保存RDB文件的目录(通常是工作目录或配置中dir指定的路径),确保Memurai有写入权限。 2. **磁盘空间不足**:如果磁盘空间不够,bgsave会失败。需要检查目标磁盘的可用空间。 3. **RDB文件路径配置错误**:检查配置文件中的dir和dbfilename是否正确设置,确保路径存在且可访问。 4. **内存不足**:在fork子进程时,如果系统内存不足,可能会导致bgsave失败。尤其是在虚拟内存管理方面,Windows可能表现不同,需要确认是否有足够的内存资源。 5. **持久化配置**:用户是否正确启用了RDB持久化?比如,save配置项是否设置,例如save 60 10000这样的指令是否存在于配置文件中。 6. **后台保存过程中的错误**:查看Memurai的日志文件,是否有具体的错误信息,比如写入失败的原因,权限被拒绝,路径不存在等。 用户提到的stop-writes-on-bgsave-error选项,如果确定问题是暂时的,或者已经解决了根本原因,可以临时关闭这个选项,允许即使保存失败也能继续写入。但这只是临时解决方案,根本问题仍需解决。 步骤可能包括: - 检查Memurai的配置文件,确认持久化设置。 - 确认目录权限和磁盘空间。 - 查看日志以获取具体错误信息。 - 调整配置,如关闭stop-writes-on-bgsave-error(不建议长期),或增加内存/解决权限问题。 另外,用户可能需要参考类似Redis的配置调整。例如,在Redis中,可以通过CONFIG SET命令动态调整配置,或者在配置文件中修改。Memurai可能支持类似的配置方式。 还需要考虑是否在Windows环境下特有的问题,例如路径格式是否正确(是否使用反斜杠或转义),防病毒软件是否阻止了文件写入,或者文件被其他进程锁定。 可能的解决方案步骤: 1. 检查并确保Memurai服务有写入目标目录的权限。可能需要以管理员权限运行,或修改目录权限。 2. 确认dir配置正确,例如dir "C:\\Memurai\\data",确保路径存在。 3. 检查磁盘空间是否足够。 4. 查看日志文件,通常在Memurai安装目录下的日志文件中,寻找与bgsave相关的错误信息。 5. 如果问题持续,尝试暂时关闭stop-writes-on-bgsave-error选项,使用命令或修改配置文件:config set stop-writes-on-bgsave-error no。但这只是临时措施。 6. 确保内存足够,尤其是在执行bgsave时,Memurai需要fork进程,虽然Windows没有fork,但Memurai可能使用其他机制模拟,需要足够的内存资源。 另外,如果用户修改了配置,可能需要重启Memurai服务,或者通过命令重新加载配置。 可能还需要检查RDB保存的频率,如果save配置过于频繁,可能导致资源紧张,尤其是在高负载情况下。调整save参数,比如减少保存频率,可能有助于缓解问题。 如果用户遇到的是持久化失败导致的数据丢失风险,可能需要同时启用AOF持久化作为补充,但需要根据具体情况考虑。 最后,建议用户综合检查配置、权限、资源和日志,逐步排除可能的原因,并测试修改后的配置是否有效。</think>### Memurai RDB快照保存失败解决方案 #### 1. 检查持久化配置 确保`memurai.conf`配置文件已启用RDB持久化并设置有效存储路径: ```conf save 900 1 # 15分钟内有至少1个键变化时保存 save 300 10 # 5分钟内有至少10个键变化时保存 dir "C:/Memurai/data" # 指定有效存储路径 dbfilename dump.rdb ``` 验证配置后通过`memurai-cli config get dir`命令确认当前存储路径[^1]。 #### 2. 排查存储环境 - **权限问题**:右键点击数据存储目录 → 属性 → 安全 → 添加`NETWORK SERVICE`用户的完全控制权限 - **磁盘空间**:确保目标盘剩余空间大于当前Memurai数据集内存占用量(通过`memurai-cli info memory`查看) - **文件锁定**:检查是否被安全软件拦截,可临时关闭实时防护测试 #### 3. 错误模式处理 ```bash # 临时关闭写入保护(需谨慎) memurai-cli config set stop-writes-on-bgsave-error no # 强制立即生成RDB快照测试 memurai-cli bgsave ``` 观察返回信息,若显示`Background saving started`则成功,否则查看日志定位具体错误。 #### 4. 内存优化配置 在配置文件中添加内存限制防止OOM: ```conf maxmemory 2gb # 根据物理内存调整 maxmemory-policy allkeys-lru ``` #### 5. 日志分析 查看Memurai日志文件(默认位于安装目录`logs`文件夹),重点关注以下错误模式: ``` [error] Failed opening .rdb for saving: Permission denied Can't save in background: fork: Cannot allocate memory Write error saving DB on disk ``` #### 6. 替代方案 若持续失败可启用AOF持久化作为补充: ```conf appendonly yes appendfsync everysec ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值