Insufficient table space for the main library users to save the space-scarce DG system through rename

Source: Internet
Author: User
Tags manual file system ftp

Sunday in order to save the main Library users table space temporarily expanded 20G tablespace, resulting in the DG Library's/bak/datafile/directory is insufficient. The log application to the extended-space archive crashes, and, more tragically, the lack of space results in an exception to the system table space writes. For this problem first think of system-level capacity expansion, through the system-level RESIZE2FS confirmed unable to enlarge. Partition merging is not possible because there are no adjacent partitions, only in the Oracle-level way. Our DG system was written to two different folders because of the shortage of space data files. Since the data can be written to two directories, can certainly write to three directories, will not be the control file has a definition, immediately created pfile, but from the pfile found no useful data file redirection information, and find information, Found a life-saving rename command, which solves the problem of data file migration through the Rename command.

File system capacity used available% mount point/dev/sda3 19G 470M 18G 3%//dev/sda12 125G 105 G 14G 89%/bak/dev/sda10 9.5G 151M 8.9G 2%/tmp/dev/sda9 9.5G 318M 8.7G 4%/va R/dev/sda8 19G 173M 18G 1%/opt/dev/sda7 19G 4.0G 14G 23%/weblogic/dev/              Sda2 48G 4.0G 41G 9%/usr/dev/sda6 48G 28G 18G 61%/home/dev/sda5 95G 76G 15G 85%/u01/dev/sda1 1.9G 42M 1.8G 3%/boot tmpfs 3.9G 0 3              .9G 0%/dev/shm [root@l-db-163-18 datafile]# umount/weblogic [root@l-db-163-18 datafile]# df-h File system  Capacity used available% mount point/dev/sda3 19G 470M 18G 3%//dev/sda12 125G 105G 14G 89% /BAK/DEV/SDA10 9.5G 151M 8.9G 2%/tmp/dev/sda9 9.5G 318M 8.7G 4%/var/dev/s DA8 19G 173M 18G 1%/opt/dev/sda2 48G 4.0G 41G 9%/usr/dev/sda6 48G 28G 18G 61%/h                 Ome/dev/sda5 95G 76G 15G 85%/u01/dev/sda1 1.9G 42M 1.8G 3%/boot Tmpfs 3.9G 0 3.9G 0%/dev/shm [root@l-db-163-18 datafile]# e2fsck-f/dev/sda12 e2fsck 1. 29-may-2006 Pass 1:checking inodes, blocks, and sizes pass 2:checking directory structure pass 3:check ing directory connectivity Pass 4:checking reference counts pass 5:checking Group summary information/bak: 24/33718272 files (12.5% non-contiguous), 28482930/33714402 blocks [root@l-db-163-18 datafile]# resize2fs/dev/sda12 1    
28G; RESIZE2FS 1.39 (29-may-2006) filesystem at/dev/sda12 is mounted on/bak;    
On-line resizing required performing an on-line-resize of/dev/sda12 to 33554432 (4k) blocks.    
The filesystem on/dev/sda12 is now 33554432 blocks long. Space is not enough to pass unmount other textThe file system needed for the expansion of the system was later carefully studied. Must be done from the partition level, try to fdisk/dev/sda\d\7\w delete useless partitions, study partition merging also does not work, because sda12 adjacent partitions have no free space, expansion from the partition level can not row, at the database level could have been through the Open database    
Data file Rename action because the system table space has not completely finished writing one thing and cannot open, rename operation error, specific as follows.    
sql> alter tablespace TEMP rename datafile '/bak/datafile/temp01.dbf ' to '/usr/datafile/temp01.dbf ';    
Alter tablespace TEMP rename datafile '/bak/datafile/temp01.dbf ' to '/usr/datafile/temp01.dbf ' * ERROR in line 1:    
Ora-01109:database not open sql> ALTER DATABASE open read only; ALTER DATABASE open Read Only * ERROR in line 1:ora-16004:backup database requires recovery ora-01196:file
        
    1 is inconsistent due to a failed media recovery session ora-01110:data file 1: '/BAK/DATAFILE/SYSTEM01.DBF '    
According to common sense, DG database can perform rename operation under Mount, but try many times but not.    
A more careful reading of the wrong information, incredibly there are the following prompts Ora-01275:operation RENAME is not allowed if standby file management is automatic.    
sql> startup Nomount;    
         
ORACLE instance started. TotAl System Global area 4596957184 bytes Fixed size 2090048 bytes Variable size 8388638 Bytes Database buffers 3741319168 bytes Redo buffers 14684160 bytes sql> alter DAT    
         
Abase mount standby database;    
         
Database altered.    
sql> ALTER DATABASE rename file '/bak/datafile/namin_data.dbf ' to '/usr/datafile/namin_data.dbf '; Alter DATABASE rename file '/bak/datafile/namin_data.dbf ' to '/usr/datafile/namin_data.dbf ' * ERROR at line 1:ora -01511:error in renaming log/data files Ora-01275:operation RENAME are not allowed if standby file management-Auto    
Matic.    
        
Oracle check, in DG Mode, the file has two kinds of management (show parameter standby can check), automatic and manual management, if it is automatic management, can not rename, immediately try to change to manual mode. Sql> Show parameter standby NAME TYPE VALUE-----------------   ------------------------------------------------------------Standby_archive_dest              String?/dbs/arch standby_file_management string AUTO sql> alter system SE    
         
T standby_file_management=manual;    
         
System altered. Sql> Show parameter standby NAME TYPE VALUE------------------ -----------------------------------------------------------standby_archive_dest string?/dbs/a RCH standby_file_management string MANUAL sql> ALTER DATABASE rename file '/bak/datafile/nami    
         
N_data.dbf ' to '/usr/datafile/namin_data.dbf ';    
         
Database altered.    
         
sql> ALTER DATABASE rename file '/bak/datafile/temp01.dbf ' to '/usr/datafile/temp01.dbf ';    
Database altered.    
The file path has been successfully changed so that the data file has been directed to the new path/usr/datafile/.    
Again this medicine note is to rename the file must be the copy of the past, or will report the following error.    
sql> ALTER DATABASE rename file '/bak/datafile/sysaux01.dbf ' to '/usr/datafile/sysaux01.dbf '; ALTER DATABASE Rename file '/bak/datafile/sysaux01.dbf ' to '/usr/datafile/sysaux01.dbf ' * ERROR at line 1:ora-01511:error in renaming log/ Data files ora-01141:error Renaming data file 3-new file '/usr/datafile/sysaux01.dbf ' not found Ora-01110:data File 3: '/bak/datafile/sysaux01.dbf ' ora-27037:unable to obtain file status linux-x86_64 error:2: No such file or di    
Rectory Additional Information:3 This space has, things are good to do, as long as the/bak/datafile/has more than 20G of space, the use of the Users table space expansion of the archive. The rest is a good thing to operate.    
Archive log full can be applied to the archive to delete, if not careful to delete the application of the archive to do, do not panic, if the use of ASM, you can use Rman from the main library to extract the archive, and then FTP to DG, if the ordinary file system, then direct FTP. eg:rman> copy archivelog ' +data/log/archivelog/2_5585_697238176.dbf ' to '/u01/rman/2_5585_697238176.dbf ';

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.