Hi, I use nextcloud on a shared hosting and since I upgraded to version 14.0.1 the indexes are no longer updated in the database and to update them I should launch this command occ db: add-missing-indices, but I can not do it since I use a shared hosting! Could you work on this problem that affects a large slice of users? thank you so much
Operating system: CentOS
Web server: Hosting Linux Aruba
Database: MySql
PHP version: 7.2.8
Nextcloud version: 14.0.1
Can second that. Happened on all instances I have updated.
GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/11167 (occ db:add-missing-indices - Exact steps to resolve?), https://github.com/nextcloud/server/issues/11463 (Missing-index), https://github.com/nextcloud/server/issues/10926 (Possible DB indexes), https://github.com/nextcloud/server/issues/10656 (Configuration check - Minor typo: occ db:add-missing-indices), and https://github.com/nextcloud/server/issues/866 (Calendar Share Functionality missing).
Hi, I use nextcloud on a shared hosting and since I upgraded to version 14.0.1 the indexes are no longer updated in the database and to update them I should launch this command occ db: add-missing-indices, but I can not do it since I use a shared hosting! Could you work on this problem that affects a large slice of users? thank you so much
There is a reason why this is a CLI command: it could take a bigger amount of time to complete and getting this command killed by the Webserver would result in a broken DB. Thus we added it to the CLI interface. Also if you run on a shared hosting instance there is not so much performance impact because usually those instances aren't that huge and only serve a handful of users. This optimization is basically for large instances that take advantage when sharing pages have hundreds of thousands of entries.
But we can check on showing the SQL statements that are needed to add those indexes then.
cc @nickvergessen @rullzer
Mine is not a large instance but still hosts 500 users and 200 GB of files. This operation could be completed without problems during web browsing, to avoid the timeout you could separate this operation from the web update and you could allow to run it optionally later "it could be a good solution"
PS: Would there be a way to directly perform this operation from phpMyAdmin?
to avoid the timeout you could separate this operation from the web update and you could allow to run it optionally later "it could be a good solution"
There is no way to separate this from web requests if there are only web requests possible. The CLI would be the timeout-free approach ;)
PS: Would there be a way to directly perform this operation from phpMyAdmin?
I will link some resources where SQL statements could be build from so the message can be improved.
Current queries to run are:
ALTER TABLE `oc_share` ADD KEY `share_with_index` (`share_with`) USING BTREE;
ALTER TABLE `oc_share` ADD KEY `parent_index` (`parent`) USING BTREE;
ALTER TABLE `oc_filecache` ADD KEY `fs_mtime` (`mtime`) USING BTREE;
Thanks a lot to everyone for the availability!
You could provide more details on how to perform queries (for those who are not a web expert like me)
Well you better google that or ask for help in the forums. We can't really give you support on administration side of things in our bugtracker.
you're right, however it was simpler than I thought :)!
PS: when I perform this operation, do I have to put the instance into maintenance? thank you
PS: when I perform this operation, do I have to put the instance into maintenance? thank you
Not needed. The DB handles this properly.
Let's close this ticket here for now as there are the SQL statements.
I launched the query on the database the result was the following:
ALTER TABLE oc_share
ADD KEYshare_with_index
(share_with
) USING BTREE; # MySQL returned an empty set (i.e. zero lines).
ALTER TABLE oc_share
ADD KEYparent_index
(parent
) USING BTREE; # MySQL returned an empty set (i.e. zero lines).
ALTER TABLE oc_filecache
ADD KEYfs_mtime
(mtime
) USING BTREE; # MySQL returned an empty set (i.e. zero lines).
Was this the result to be obtained?
Assuming there could be code that can estimate if the query could be successful given the maximum script execution time configuration. If that is within the estimated limit, the query could be executed in the browser. In several of the instances, I have updated it took between 2-10 seconds to complete.
Thank you have a nice day !
@ddi98, is the warning gone from Nextcloud after you ran the query? If not, are you running it against the Nextcloud database?
Assuming there could be code that can estimate if the query could be successful given the maximum script execution time configuration. If that is within the estimated limit, the query could be executed in the browser. In several of the instances, I have updated it took between 2-10 seconds to complete.
I'm not aware of any estimations like this. :/
the warning was returned by phpmyadmin, so the operation was not successful?
Was this the result to be obtained?
Looks good, because adding an index does not return anything.
@MorrisJobke, assuming the amount of time required for a query of that type to complete is based on the number of records in the given table. Thinking about it, that doesn't say much about the speed of database procedures (disk IOPS, ram, available CPU time, etc)...
In any case, the request turns out to be much more powerful!
It would be nice to add these queries in the official documentation
The queries are working as expected, adding the indexes and the warning is gone after execution. (14.0.1)
The three queries mentioned above solved three issue. The following remain:
Fehlender Index "owner_index" in der Tabelle "oc_share".
Fehlender Index "initiator_index" in der Tabelle "oc_share".
Current queries to run are:
ALTER TABLE `oc_share` ADD KEY `share_with_index` (`share_with`) USING BTREE; ALTER TABLE `oc_share` ADD KEY `parent_index` (`parent`) USING BTREE; ALTER TABLE `oc_filecache` ADD KEY `fs_mtime` (`mtime`) USING BTREE;
Hello, I reopened the discussion to which you gave me solution some time ago :), after updating to nextcloud 15.0.2 a similar problem has resurfaced, would you be so kind to help me? :)
these are the errors:
The database is missing some indexes. Due to the fact that adding indexes on big tables could take some time they were not added automatically. By running "occ db:add-missing-indices" those missing indexes could be added manually while the instance keeps running. Once the indexes are added queries to those tables are usually much faster.
Missing index "owner_index" in table "oc_share".
Missing index "initiator_index" in table "oc_share".
Some columns in the database are missing a conversion to big int. Due to the fact that changing column types on big tables could take some time they were not changed automatically. By running 'occ db:convert-filecache-bigint' those pending changes could be applied manually. This operation needs to be made while the instance is offline. For further details read the documentation page about this.
filecache.fileid
filecache.storage
filecache.parent
filecache.mimetype
filecache.mimepart
filecache.mtime
filecache.storage_mtime
mimetypes.id
storages.numeric_id
Please check here:
https://github.com/nextcloud/server/issues/13578
I summarized what helped for me.
But we can check on showing the SQL statements that are needed to add those indexes then.
@MorrisJobke Is there any open issue which tracks your idea? Because i - and many others, which are unable to use the occ component, would really appreciate if you would provide the required SQL commands right with the error inside the settings page of nextcloud (or at least a link).
@MorrisJobke Is there any open issue which tracks your idea? Because i - any many others, which are unable to use the occ component, would really appreciate if you would provide the required SQL commands right with the error inside the settings page of nextcloud (or at least a link).
Not really - let's reopen this for now.
It's really frustrating to google for the queries after each update. Is there any document available which is always up-to date and lists the queries which must be executed after each update?
Missing Index "twofactor_providers_uid" in table "oc_twofactor_providers".
Missing Index "version" in table "oc_whats_new".
Missing Index "cards_abid" in table "oc_cards".
Missing Index "cards_prop_abid" in table "oc_cards_properties".
-- MySQL
ALTER TABLE `oc_whats_new` ADD KEY `version` (`version`) USING BTREE;
ALTER TABLE `oc_twofactor_providers` ADD KEY `twofactor_providers_uid` (`uid`) USING BTREE;
ALTER TABLE `oc_cards` ADD KEY `cards_abid` (`addressbookid`) USING BTREE;
ALTER TABLE `oc_cards_properties` ADD KEY `cards_prop_abid` (`addressbookid`) USING BTREE;
ref https://help.nextcloud.com/t/missing-indices-on-nc16/52284
15.0.7 > 16.0.1.
As it seems that this is not going to be implemented in the near feature, isn't it?
The OCC Web app (https://apps.nextcloud.com/apps/occweb) is a good approach, but unfortunately it seems like it isn't really well maintained as there's no official version for Nextcloud 16 available.
ich habe folgende Fehlermeldung (leider keine L枚sung ergoogled) wenn ich in meinem phpmyadmin dies hier eingebe:
ALTER TABLE
oc_share
ADD KEYshare_with_index
(share_with
) USING BTREE;
ALTER TABLEoc_share
ADD KEYparent_index
(parent
) USING BTREE;
ALTER TABLEoc_filecache
ADD KEYfs_mtime
(mtime
) USING BTREE;
Fehler
SQL-Befehl:
ALTER TABLE oc_share
ADD KEY share_with_index
(share_with
) USING BTREE
MySQL meldet: Dokumentation
#1061 - Doppelter Name f眉r Schl眉ssel vorhanden: 'share_with_index'
Was kann ich noch machen um mein Problem zu l枚sen?
english:
I have the following error message (unfortunately no solution ergoogled) if I enter this in my phpmyadmin this:
ALTER TABLE
oc_share
ADD KEYshare_with_index
(share_with
) USING BTREE;
ALTER TABLEoc_share
ADD KEYparent_index
(parent
) USING BTREE;
ALTER TABLEoc_filecache
ADD KEYfs_mtime
(mtime
) USING BTREE;
error
SQL command:
ALTER TABLE oc_share
ADD KEYshare_with_index
(share_with
) USING BTREE
MySQL reports: Documentation
# 1061 - Duplicate key name exists: 'share_with_index'
What else can I do to solve my problem?
Duplicate key name exists: 'share_with_index'
The index with the name share_with_index
is already present. Skip this one and execute the next alter table statement.
thanxs for tis fast support.
But in the backend of my NC15 i have follow message:#
In der Datenbank fehlen einige Indizes. Auf Grund der Tatsache, dass das Hinzuf眉gen von Indizes in gro脽en Tabellen einige Zeit in Anspruch nehmen kann, wurden diese nicht automatisch erzeugt. Durch das Ausf眉hren von "occ db:add-missing-indices" k枚nnen die fehlenden Indizes manuell hinzugef眉gt werden, w盲hrend die Instanz weiter l盲uft. Nachdem die Indizes hinzugef眉gt wurden, sind Anfragen auf die Tabellen normalerweise schneller.
Fehlender Index "parent_index" in der Tabelle "oc_share".
Fehlender Index "owner_index" in der Tabelle "oc_share".
Fehlender Index "initiator_index" in der Tabelle "oc_share".
Fehlender Index "fs_mtime" in der Tabelle "oc_filecache".
How i solve this?
Please check here:
13578
I summarized what helped for me.
@MichaSei
What about the occ shell app for shared environment?
Does it work?
occ shell does work on our Strato hosted website. NC 16.0.1
I see occ
is supposed to be use "as your HTTP user", and with the http server's version of PHP. I'm using shared hosting but I do have shell access (webfaction - platform as a service) . All files in my nextcloud install are owned by my shell user.
Also, I have to second @FireEmerald 's frustration.
In your shell run:
php --version
if that works, try the following in your nextcloud directory:
php occ
Most helpful comment
Current queries to run are: