oracle 数据文件太大 太多如何处理 （具体数据有几十个oracle 用户,表空间文件有上百G）

Posted 2023-05-17

因为文件太大 太多导致oracle 启动跟运行极慢。 有没有什么办法能解决这个问题，或者什么方案可以暂时停用一些用户 （正常使用的一般是三个用户左右）

启动和运行太慢也许和数据库的配置有太多的关系。SGA或者PGA的内存分配啊什么的。另外如果查询速度过慢也可能和表空间的使用率过大没有过大的剩余表空间有关，如果有过程，而且使用临时表，则可能是临时表空间的使用率过高没有和几乎没有剩余表空间有关系。你可以从v$datafiles

视图中查看下个个数据文件的使用和剩余情况。追问

SGA与PGA内存也调整了
机器CPU是Intel 8核　　内存是32G

追答

这也要看什么系统？如果是32系统是有限制的。因为32位的db只能识别到3.7G的内存。所以内存占比即使分配的再大也没有作用的。所以建议使用64系统和64位版本的数据库。对应这也的情况，建议使用Oracle的集群解决方案。或者开启Oralce的Web Server 查看在使用过程中的磁盘吞吐量，锁定的情况。在创建数据库的时候，你是使用的专有还共享服务器模式？这两个模式的配置也是很重要的。如果是共享，一个进程中的用户资源出现锁定的情况，那么同一个进程的其他用户都会被卡死。总的来说，这样的情况，在开始创建数据库的时候配置是很重要的。

参考技术A 你这个不算多

运行慢 应该从两个方面考虑 一 机器的性能

二 数据库的调优，

至于几百G数据，几十个SCHma 很一般的 参考技术B 这个 我也不懂.3333 参考技术C 你是把所有的用户和数据什么的都放到1个表空间里了么....追问

每个用户都有一个独立的表空间与临时表空间

追答

看你的机器配置不错不低,那你还不如把常用的那几个用户数据导出来放到新建的数据库实例里面,然后平时用哪个启动哪个,可以多建几个数据库实例,这样实例非开启动的话每个都会快很多,唯一的不足就是实例多了会比较占用内存,但是你8U 32G的内存足够了

大数据之Hive：hive的小文件如何处理

目录

• 1.小文件如何产生的？
• 2.小文件解决方案

1.小文件如何产生的？

（1）动态分区插入数据，分区数太多，产生大量的小文件，导致map数量剧增；
（2）reduce数量越多，小文件也越多（reduce的个数和输出文件是对应的）；
（3）数据源本身就包含大量的小文件。

2.小文件解决方案

（1）在Map执行前合并小文件，减少Map数：
CombineHiveInputFormat具有对小文件进行合并的功能（系统默认的格式）。HiveInputFormat没有对小文件合并功能。

set hive.input.format=org.apache.hadoop.hive.al.io.CombineHiveInputFormat

（2）merge
输出合并小文件

SET hive.merge.mapfiles = true; # 默认true，在map-only任务结束时合并小文件
SET hive.merge.mapredfiles = true;#默认false，在map-reduce任务结束时合并小文件
SET hive.merge.size.per.task = 268435456; #默认256M
SET hive.merge.smallfiles.avgsize = 16777216; # 当输出文件的平均大小小于16m该值时，启动一个独立的map-reduce任务进行文件merge

（3）开启JVM重用
JVM重用是Hadoop调优参数的内容，其对Hive的性能具有非常大的影响，特别是对于很难避免小文件的场景或task特别多的场景，这类场景大多数执行时间都很短。
Hadoop的默认配置通常是使用派生JVM来执行map和Reduce任务的。这时JVM的启动过程可能会造成相当大的开销，尤其是执行的job包含有成百上千task任务的情况。JVM重用可以使得JVM实例在同一个job中重新使用N次。N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间，具体多少需要根据具体业务场景测试得出。默认值是1

<property>
  <name>mapreduce.job.jvm.numtasks</name>
  <value>10</value>
  <description>How many tasks to run per jvm. If set to -1, there is no limit. </description>
</property>

这个功能的缺点是，开启JVM重用将一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。如果某个“不平衡的”job中有某几个reduce task执行的时间要比其他Reduce task消耗的时间多的多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。