Hello, Please never truncate the oc_filecache table! You will lose all shares and other information associated with files.
We should really rename it to oc_fileindex to prevent people thinking it's a cache that can be cleared. I'll raise a ticket for that. The reason it's copying the table is to do an "update simulation" to make sure that the database schema change will work. You can skip the simulation by passing an extra argument to occ: ./occ upgrade --skip-migration-test Konsole output Cheers, Vincent On 01.08.2015 01:29, [email protected] wrote: >>>>>> "Arman" == Arman Khalatyan <[email protected]> writes: > Arman> [1 <multipart/alternative (7bit)>] [1.1 <text/plain; UTF-8 > Arman> (quoted-printable)>] Hi, > > Arman> You can try several things: 0) look in tto php logs and > Arman> owncloud.log files 1) look on mysql server with "mytop" the > Arman> mysql activity. 2) on the serverwhere occ is running you can > Arman> try strace -p PID_of_occ_process 3) with lsof | grep > Arman> PATH_to_your_owncloud installation check the progress of scan. > > It's trying to do > insert into oc_oc_filecache_f225ece9c79eb select * from oc_filecache; > > which tries to copy 7 million rows in one transaction!!! > > This of course stalls almost everything else. > > I truncated oc_filecache then restarted the upgrade and it took only a > few seconds. > > Peter C > _______________________________________________ > User mailing list > [email protected] > http://mailman.owncloud.org/mailman/listinfo/user
signature.asc
Description: OpenPGP digital signature
_______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
