大概700G的数据用了下面的导入语句:
impdp
但是发现导数在半夜突然因为system表满了停了下来,看到近乎30G的system表空间完全满了,不像是日志文件的样子。。。前前后后弄了很久
解决方案如下:
impdp aeis_xx/密码@IP:端口/orcl directory=DATA_PUMP_DIR(数据字典名称) dumpfile =20200909_01_%U.
dump
contennt=DATA_ONLY job_name=0916 logfile=0916.log cluster=n remap_schema =cacher02:aeis_xx
这样就好了。怀疑原因是因为没有使用指定的用户登录,导致数据放在了system表下面
心态逐渐爆炸过程中,记着导入语句的执行路径:
su - oracle
后面可以查看导入进度的语句:
查看表空间:
Select A.Tablespace_Name,
A.Bytes / 1024 / 1024 /1024"Sum GB",
(A.Bytes - B.Bytes) / 1024 / 1024 /1024 "used GB",
B.Bytes / 1024 / 1024 /1024 "free GB",
Round(((A.Bytes - B.Bytes) / A.Bytes) * 100, 2) "percent_used"
From (Select Tablespace_Name, Sum(Bytes) Bytes
From Dba_Data_Files
Group By Tablespace_Name) a,
(Select Tablespace_Name, Sum(Bytes) Bytes, Max(Bytes) Largest
From Dba_Free_Space
Group By Tablespace_Name) b
Where A.Tablespace_Name = B.Tablespace_Name
Order By ((A.Bytes - B.Bytes) / A.Bytes) Desc;
增加数据文件:
alter tablespace SYSTEM add datafile '/home/data/oracle/orcl/system02.dbf'
size 10G autoextend off ;
突然想起来了个东西,当时问朋友有没有遇到类似i的问题,怀疑是表空间建立在system下面,然后就想去查查,当时用的语句是:
select tablespace_name from all_tables where table_name =
查了几个发现有的是空值
然后就去搜了下,可能是因为分区表,索引组织表,临时表,在all_tables 下面无法查到,应该使用下面的语句:
select distinct tablespace_name from DBA_segments where segment_name =
这样就好了