⑴ linux安装oracle12数据库设置内存时报错
图形界面出不来；
在root下面执行：
xhost +
再su过去oracle用户安装。
⑵ h2数据库在linux服务器怎么使用
简单来说就是用jdbc:h2:mem:h2db来建立内存模式，并建表， 然后jdbc:h2:tcp://192.168.20.141:8082/mem:h2db来访问上面的内存数据库 package test; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; imp...
⑶ Linux里面什么是数据持久化
数据持久化顾名思义就是把程序中的数据以某种形式保存到某存贮介质中，以达到持久化的目的。当程序运行时，一些数据是临时保存在内存中，一旦退出系统，这些数据就丢失了。那么，使用某种手段将数据保存在硬盘上或者数据库中，这样即使退出系统后又重新启动系统，那么这些数据仍然可以重新找回来。
例如管理员向一个用户管理系统中添加了一个用户的资料，那么这个系统需要将新添加的资料保存到数据库中，否则系统退出或者电脑重启后该用户资料就会丢失。将数据从内存保存到数据库中，这便是数据的持久化。当然，数据库只是持久化方式中的一种，也可以保存在其他的永久存贮介质中。
图为数据持久化的过程示意图。
持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。
持久化是将程序数据在持久状态和瞬时状态间转换的机制。
DBC就是一种持久化机制。文件IO也是一种持久化机制。
日常持久化的方法
在一定周期内保持不变就是持久化,持久化是针对时间来说的。数据库中的数据就是持久化了的数据,只要你不去删除或修改。比如在浏览器中一次Session会话中Session对象变量也是不变的,是Session容器中持久化。对象持久化的方式有很多种,根据周期不同有,page,Session,Application。对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态. 对象序列化的过程是对象持久化的方法之一,把对象保存到文件中。
简单的理解持久化可以在二个层面：应用层和系统层、
应用层
如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。
系统层
如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。
持久化是一种对象服务实现至少3个接口
，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：
void Save(object o) 把一个对象保存到外存中
Object Load(object oid) 通过对象标识从外存中取回对象
boolExists(object oid) 检查外存中是否存在某个对象.
类似概念序列化
我们先跳开一下，看看另一个类似的有用概念：序列化Serialize也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：
void Serialize(Stream stream,object o) 把对象序列化到流中
object Deserialize(Stream stream) 把流反序列化成对象
序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在线程之间、进程之间、内存外存之间、主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。
持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案
现今主流的持久化方案是关系数据库方案，
关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。关系数据库和面向对象之间有一条鸿沟，因为二者模式不匹配，所以就存在一个OR映射问题。
Redis支持两种数据持久化方式：rdb方式和aof方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。
1、RDB方式
RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，redis默认开启该持久化功能，具体配置如下：
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename mp.rdb
#文件名称
dir ./
#rdb文件存放路径
配置后系统会自动进行快照，save 60 10000表示60秒内有10000次写入，那么就会调用bgsave
除了系统自动进行快照外，我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作：
执行SAVE或BGSAVE命令
执行FLUSHALL命令
2、AOF方式
在使用Redis存储非临时数据时，一般都需要打开AOF持久化来降低进程终止导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能。
默认情况下，Redis没有开启AOF（append only file）持久化功能，可以通过在配置文件中作如下配置启用：
appendonly no #是否开启aof，开启时将no改为yes
appendfilename "appendonly.aof" 持久化文件名称
auto-aof-rewrite-percentage 100
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
appendfsync :everysec (推荐配置)
#持久化策略
always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)
everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)
no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）
一般来说可以考虑同时使用两种持久化方案.
⑷ linux数据库服务器占用内存过高，是怎么回事
修改mysql配置文件，优化缓存大小和连接数连接方式，优化sql语句 ,记得mysql好像是有工具可以查看最占用资源的sql语句，找到他，优化他。
安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境，当然需要有不同的配制文件了。
一般的情况下，my-medium.cnf这个配制文件就能满足我们的大多需要；一般我们会把配置文件拷贝到/etc/my.cnf 只需要修改这个配置文件就可以了，使用mysqladmin variables extended-status –u root –p 可以看到目前的参数，有3个配置参数是最重要的，即key_buffer_size,query_cache_size,table_cache。
key_buffer_size只对MyISAM表起作用，
key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。一般我们设为16M,实际上稍微大一点的站点这个数字是远远不够的，通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例 key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）。 或者如果你装了phpmyadmin 可以通过服务器运行状态看到,笔者推荐用phpmyadmin管理mysql，以下的状态值都是本人通过phpmyadmin获得的实例分析:
这个服务器已经运行了20天
key_buffer_size – 128M
key_read_requests – 650759289
key_reads - 79112
比例接近1:8000 健康状况非常好
⑸ Postgresql-9.1.5-1-linux-x64是内存数据库吗
应该不是的，内存数据库相当于把数据cache到内存中，提高访问效率，因为几乎没有磁盘I/O，我知道的是ORACLE有内存数据库timesten，但是我之前用的时候是和Oracle的数据库配合使用以提高Application与DB之间的访问效率，内存数据应该也可以单独使用。 反正Postgresql应该不是啦
⑹ Linux数据库服务器物理内存和虚拟内存满了怎么排查和解决
一、查看物理内存
执行如下命令即可查看物理内存，执行效果如下图所示：
dmidecode -t memory | grep Size
二、配置空间
物理内存是没办法配置的，只能配置虚拟内存，在Linux系统即Swap分区。具体操作swap分区的方法如下：
⑺ 如何使用 Linux Huge Pages 配置大型数据库的 x86 内存性能
大型数据库系统的性能调优颇具挑战性。根据操作系统 (OS) 和硬件的不同，有些性能问题可能难以通过常规分析方法（如 AWR 报表）和操作系统工具（如 sar、top 和iostat）来检测。
x86 环境中的内存利用率就是一个难以识别的问题，但如果分析和配置得当，可显着提升性能。
想对本文发表评论吗？请将链接发布在 Facebook 的 OTN Garage 页面上。有类似文章要分享？请将其发布在 Facebook 或 Twitter 上，我们来进行讨论。
现在的系统内存更大，内存利用率成为一个亟待解决的重要问题。本文介绍如何最佳配置大型数据库的 x86 系统内存性能。
适用于 x86 平台的虚拟内存架构
与最初时相比，x86 和 x86-64 芯片组的内存架构已经发生巨大变化；但默认内存页面大小却一直未变。遇到使用大量内存的大型应用程序（如数据库）时，这可能导致效率低下或开销过大。
x86 架构是一种虚拟内存架构，其允许寻址范围超过硬件中的可用物理内存。这通过允许每个进程拥有自己可寻址的内存来实现。该进程认为此内存是专供自己使用的。这称为进程的虚拟内存。实际上，此内存可以是实际驻留于 RAM 芯片上的物理内存，也可以存储在物理磁盘上被称作交换区 或分页区 的专用区域中。
进程不知道虚拟内存是存储在 RAM 中还是磁盘上；内存由操作系统管理。如果所需内存超过可用物理内存，操作系统会将一些内存移出到分页区。这种活动效率极低，是导致性能问题的常见原因。由于磁盘的存取速度远低于 RAM，“分页”的进程会遇到显着的性能问题。
Oracle 数据库和 Linux 内存管理
系统中使用的内存越多，管理该内存所需的资源也就越多。对于 Linux 操作系统，通过 Linux kswapd 进程和页表内存结构（针对系统中存在的每个进程包含一条记录）实现内存管理。每条记录包含进程使用的每页虚拟内存及其物理地址（RAM 或磁盘）。通过使用处理器的转换旁路缓冲区（TLB，一小块缓存）为该进程提供帮助。
当大量内存用于 Oracle 数据库时，操作系统将消耗大量资源来管理虚拟地址到物理地址转换，其结果往往是一个非常大的页表结构。由于每条页表条目包含进程正在使用的所有内存页面的虚拟地址到物理地址的转换，因此对于非常大的系统全局区 (SGA)，每个进程的页表条目都可能很大。例如，使用 8 GB 内存的 Oracle 数据库进程的页表条目将达 8 GB/4 KB（即 2097152 条记录或页面）。如果有 100 个 Oracle 数据库会话/进程，则将页面数乘以 100。您可以看到，要管理的页面数量巨大。
同样，操作系统使用页表条目管理系统中进程所用的内存。在 Linux 中，执行此管理的操作系统进程被称作 kswapd，可在操作系统工具中找到。
TLB 缓存将缓存页表条目来提高性能。典型的 TLB 缓存可保存 4 到 4096 个条目。对于数百万甚至数十亿个页表条目，这种缓存就不够用了。
如上所述，对于使用大型 SGA 的系统，页表结构可能会变得非常大。清单 1 中的 Linux 系统输出示例显示页表条目占用了 766 MB 的 RAM。这可能导致显着的系统开销。我亲眼见过数 GB 的页表条目。
HugePages 是 Linux 操作系统的一个内核特性，让操作系统可以支持现代硬件架构的大页面容量功能。对于 Oracle 数据库，通过启用 HugePages 并使用大页面，可以用一个页表条目代表一个大页面，而不是使用许多条目代表较小的页面，从而可以管理更多内存，减少操作系统对页面状态的维护并提高 TLB 缓存命中率。在 Linux 中，大页面大小为 2 MB。
在 Oracle Linux 6 或 Red Hat Enterprise Linux 6 (RHEL 6) 中，可在 /proc/meminfo 中找到分配的 HugePages 数，如清单 1 所示：
[root@ptc1 ~]# cat /proc/meminfo
MemTotal: 4045076 kB
MemFree: 14132 kB
Buffers: 656 kB
Cached: 1271560 kB
SwapCached: 6184 kB
Active: 2536748 kB
Inactive: 625616 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 4045076 kB
LowFree: 14132 kB
SwapTotal: 1052216 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
Mapped: 2036576 kB
Slab: 49712 kB
CommitLimit: 3074752 kB
Committed_AS: 8054664 kB
PageTables: 766680 kB
VmallocTotal:536870911 kB
VmallocUsed: 263168 kB
VmallocChunk:536607347 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB
清单 1
在 Oracle Linux 6 中，分配的 HugePages 略有不同，如清单 2 所示：
AnonHugePages: 0 kB
HugePages_Total: 1508
HugePages_Free: 60
HugePages_Rsvd: 57
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 10240 kB
DirectMap2M: 16766976 kB
清单 2
Oracle Linux 6 HugePages 值如下所示：
AnonHugePages。匿名 HugePages 数量。Oracle Linux 6.5 中已删除此计数器。与透明 HugePages 有关。（有关透明 HugePages 的详细信息，请参见“透明 HugePages 和 Oracle 数据库”一节。）
HugePages_Total。HugePages 数量。空间大小为 HugePages 数乘以 2M。
HugePages_Free。池中尚未分配的 HugePages 数量。
HugePages_Rsvd。“reserved”的缩写形式，表示池中已经承诺分配但尚未分配的 HugePages 数量。保留的 HugePages 保证应用程序随时请求都能够从 HugePages 池分配 HugePages，即使系统已经运行一段时间。
HugePages_Surp。“surplus”的缩写形式，表示池中大于 /proc/sys/vm/nr_hugepages 中值的 HugePages 数量。剩余 HugePages 的最大数量由 /proc/sys/vm/nr_overcommit_hugepages 控制。此值为 0 的情况很常见。
Hugepagesize。HugePage 的大小。此参数当前为 2048 或 2 MB。
解决方案
通过在 Linux 中启用 HugePages，可以通过增大页面大小来减少 TLB 条目数。对于 Linux，HugePages 大小为 2 MB。通过为 Oracle 数据库 SGA 选用更大的页面，可大大减少要管理的页面数。
在清单 1 所示示例中，单条记录的虚拟地址到物理地址转换数将从 2097152 减少至 4096。这将减小页表结构的大小，提高 TLB 命中率，并降低 kswapd 使用率。
注：启用 HugePages 可显着提升性能。
在 Linux 中启用 HugePages
在 Linux 中，通过将 Linux 初始化参数 vm.nr_hugepages 设置为您希望为 Oracle 数据库 SGA 提供的 2 MB 页面数来配置 HugePages 功能。设置此参数可通过将其值调大来减少页面数。
注：Oracle Database 11g 中引入的 Oracle 数据库自动内存管理特性与 Linux HugePages 不兼容。HugePages 提供的性能改进优于自动内存管理所提供的易用性。
有关如何实现 HugePages 配置的详细信息，可在表 1 所示的 My Oracle Support 文档中找到。
表 1. My Oracle Support 文档
My Oracle Support 文档 ID
文档名称
1557478.11557478.1 “通知：SLES11、RHEL6、OEL6 和 UEK2 内核上禁用透明 HugePages”
361323.1 “Linux 上的 HugePages：它是什么……它不是什么”
361468.1 “Oracle Linux 64 位上的 HugePages”
749851.1 “Linux 上的 HugePages 和 Oracle Database 11g 自动内存管理 (AMM)”
1134002.1 “ASMM 和 LINUX x86-64 HugePages 支持”
401749.1 “用于计算推荐的 Linux HugePages/HugeTLB 配置的值的 Shell 脚本”
除了配置 vm.nr_hugepages，还可以将可选的 vm.hugetlb_shm_group 参数设置为有权使用 HugePages 的操作系统组。默认情况下，此参数设置为 0，从而允许所有组使用 HugePages。可以将此参数设置为 Oracle 数据库进程所属的操作系统组，如 oinstall。
验证是否已对 Oracle 数据库实例启用大页面
可以通过检查警报日志来验证是否对数据库实例启用了大页面。启动实例时，您应在警报日志中参数列表前面看到如下内容：
****************** Large Pages Information *****************
Total Shared Global Region in Large Pages = 28 GB (100%)
Large Pages used by this instance: 14497 (28 GB)
Large Pages unused system wide = 1015 (2030 MB) (alloc incr 64 MB)
Large Pages configured system wide = 19680 (38 GB)
Large Page size = 2048 KB
透明 HugePages 和 Oracle 数据库
最近，RHEL 6、Oracle Linux 6 和 SUSE Linux Enterprise Server 11 中引入了一个新特性 — 透明 HugePages。透明 HugePages 旨在自动、动态地利用 HugePages。遗憾的是，目前透明 HugePages 与传统 HugePages 联用会出现一些问题，导致性能问题和系统重启。在 My Oracle Support 说明 1557478.11557478.1 中，Oracle 建议不要同时使用透明 HugePages 和 Oracle 数据库。
注：在 Oracle Linux 6.5 版中，已删除透明 HugePages。
总结
通过使用更大的页面，可以减少页表条目数，从而最大程度减少开销。使用 HugePages 可显着提升性能，增加系统中的内存数量和 SGA 大小。