Thanks a lot Duncan,Lisa:)
As guided above compaction activity completed successfully after moving the p0004_nDiscoveredCommandResult_pidx file to /usr/tideway and then create the softlink for the same.
Also after compaction ,I have deleted the symbolic link and mv the file back to the original place.(/mnt/addm/db_data/data/datadir)
[tideway@cltdvladmc01 datadir]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 960M 270M 640M 30% /
tmpfs 28G 0 28G 0% /dev/shm
/dev/sda1 239M 36M 191M 16% /boot
/dev/sda6 1.5G 2.3M 1.4G 1% /home
/dev/sda3 1.9G 51M 1.8G 3% /tmp
/dev/sda10 255G 109G 133G 46% /usr
/dev/sda5 1.7G 139M 1.5G 9% /var
/dev/sda8 852M 89M 719M 11% /var/log
/dev/sda9 852M 28M 780M 4% /var/log/audit
/dev/sdb2 1.1T 606G 369G 63% /mnt/addm/db_data
2 of 2 people found this helpful
It was a mistake to move the original file back -- the compaction would have written a new, smaller version of it. The database contents will be the same, but there are sequence numbers in the file that might cause it to fail. Did you really overwrite the newly written p0004_nDiscoveredCommandResult_pidx file with the original uncompacted one?
I have moved the original fileback.
[tideway@cltdvladmc01 datadir]$ du . -a |sort -n -r|head -n 5
Yes I had overwrite the newly written p0004_nDiscoveredCommandResult_pidx file with the original uncompacted one.
Would that be an issue ?
1 of 1 people found this helpful
Yes, it will be an issue, because at some point the system will try to access data in that file, and it will be upset that the sequence numbers are not in the range it expects.
The simplest way to fix it is to do the compaction again, because that will write the files again. This time you have plenty of space, so you can just run the compaction without having to mess around moving any files about.
Thanks a lot Duncan.I will do the same.