Facebook
Twitter
- Server operating system version
- Alma 8, but applies to other OS, too
- Plesk version and microupdate number
- 18.0.77 #2
While this short input explains removal issues with a database previously used with Joomla, similar issues might appear with other former APS applications that can no longer be removed through the APS catalog, because the feature was completely removed. Hence it appears that such databases can never be removed.
A customer had installed Joomla through the APS catalog, not through the Joomla toolkit. Lately, the APS catalog was removed from Plesk. The customer removed his Joomla website afterwards. This left him with an orphaned database that denied removal, because the APS catalog removal did not cleanly check dependencies.
We were able to remove that database following the instructions from https://support.plesk.com/hc/en-us/...resource-is-used-by-installed-web-application. Let's first note that the information in that article is incomplete. Because removing the database will cause a new error during a server backup (both, full or incremental):
Here it becomes tricky, because no "id" given in the error message, just blank space, as the important information is no longer available in the psa database. A bad error, because only if you luckily remember the id previously used in the solution from https://support.plesk.com/hc/en-us/...resource-is-used-by-installed-web-application you can fix this more or less easily.
According to https://support.plesk.com/hc/en-us/...nable-to-find-row-with-id-in-data-bases-table we should run "plesk repair db". But that article does not explain it correctly either, as a "plesk repair web" at this stage results in a perfect output:
So how to proceed? We'll need to first remove APS catalog references manually, then fix the consistency of the database automatically.
1) Make a full dump of the psa database.
If anything goes wrong, you can restore it by
2) In psa.apsResources find the datasets with pleskID like the id you needed to remove the lock from the database (as described in https://support.plesk.com/hc/en-us/...resource-is-used-by-installed-web-application). Let's say the id of the APS installation was 124, then search for pleskId 124 in the apsResources table. Then note the id of that apsResources dataset and remove all entries from psa.apsResourcesParameters that match that ID, e.g.
3) Remove the datasets from apsResources itself, g.
4) Find the datasets in apsContexts that match the pleskID (in our example 124), note their ids and remove them, e.g.
You could also remove them like
which is more direct. Personally I prefer more control over such processes so I make myself aware of the full picture and references between tables before manipulating them. For that reason I rather address the datasets I want to remove with their id.
5) Now the issue is almost solved. The rest can be handled by
which will now detect the incorrect consistency with apsContexts, apsContextsApplications and some smb_* tables, and fix it for us:
A customer had installed Joomla through the APS catalog, not through the Joomla toolkit. Lately, the APS catalog was removed from Plesk. The customer removed his Joomla website afterwards. This left him with an orphaned database that denied removal, because the APS catalog removal did not cleanly check dependencies.
We were able to remove that database following the instructions from https://support.plesk.com/hc/en-us/...resource-is-used-by-installed-web-application. Let's first note that the information in that article is incomplete. Because removing the database will cause a new error during a server backup (both, full or incremental):
Here it becomes tricky, because no "id" given in the error message, just blank space, as the important information is no longer available in the psa database. A bad error, because only if you luckily remember the id previously used in the solution from https://support.plesk.com/hc/en-us/...resource-is-used-by-installed-web-application you can fix this more or less easily.
According to https://support.plesk.com/hc/en-us/...nable-to-find-row-with-id-in-data-bases-table we should run "plesk repair db". But that article does not explain it correctly either, as a "plesk repair web" at this stage results in a perfect output:
Code:
Checking the Plesk database using the native database server tools .. [OK]
Checking the structure of the Plesk database ........................ [OK]
Checking the consistency of the Plesk database ...................... [OK]So how to proceed? We'll need to first remove APS catalog references manually, then fix the consistency of the database automatically.
1) Make a full dump of the psa database.
plesk db dump psa > /home/some-path/psa_dump.sqlIf anything goes wrong, you can restore it by
plesk db < /home/some-path/psa_dump.sql2) In psa.apsResources find the datasets with pleskID like the id you needed to remove the lock from the database (as described in https://support.plesk.com/hc/en-us/...resource-is-used-by-installed-web-application). Let's say the id of the APS installation was 124, then search for pleskId 124 in the apsResources table. Then note the id of that apsResources dataset and remove all entries from psa.apsResourcesParameters that match that ID, e.g.
Code:
DELETE FROM apsResourcesParameters WHERE apsResourceId LIKE '1971';
DELETE FROM apsResourcesParameters WHERE apsResourceId LIKE '1972';3) Remove the datasets from apsResources itself, g.
Code:
DELETE FROM apsResources WHERE id LIKE '1971';
DELETE FROM apsResources WHERE id LIKE '1972';4) Find the datasets in apsContexts that match the pleskID (in our example 124), note their ids and remove them, e.g.
DELETE FROM apsContexts WHERE id LIKE '411';You could also remove them like
DELETE FROM apsContexts WHERE pleskID LIKE '124';which is more direct. Personally I prefer more control over such processes so I make myself aware of the full picture and references between tables before manipulating them. For that reason I rather address the datasets I want to remove with their id.
5) Now the issue is almost solved. The rest can be handled by
plesk repair db -ywhich will now detect the incorrect consistency with apsContexts, apsContextsApplications and some smb_* tables, and fix it for us:
Code:
Checking the Plesk database using the native database server tools .. [OK]
Checking the structure of the Plesk database ........................ [OK]
Checking the consistency of the Plesk database
Inconsistency in the table 'apsContextsApplications' for the column
apsContextId: No rows in the table 'apsContexts' with id = 411 .... [WARNING]
To see more details, run the command in the verbose mode: plesk repair db -verbose
Remove unnecessary rows from the table 'apsContextsApplications'? [Y/n] Y
Creating a database dump ........................................ [OK]
A dump of the database was created before an attempt to repair the database: /home/dumps/mysql.preresolve.20260508-092010.dump.gz
Removing unnecessary rows ....................................... [FIXED]
Inconsistency in the table 'apsInstancesParameters' for the column
instanceId: No rows in the table 'apsContextsApplications' with id =
428 ............................................................... [WARNING]
To see more details, run the command in the verbose mode: plesk repair db -verbose
Remove unnecessary rows from the table 'apsInstancesParameters'? [Y/n] Y
Removing unnecessary rows ....................................... [FIXED]
Inconsistency in the table 'smb_apsInstances' for the column
registryResourceId: An APS application for the APS database entry
with ID = 428 was not found ....................................... [ERROR]
Remove the APS entry? [Y/n] Y
Removing the APS entry .......................................... [FIXED]
Inconsistency in the table 'smb_serviceInstances' for the column
externalId: No rows in the table 'smb_apsInstances' with
registryResourceId = ec82d130-1fc1-48af-859e-efa98a402ed2 ......... [WARNING]
To see more details, run the command in the verbose mode: plesk repair db -verbose
Remove unnecessary rows from the table 'smb_serviceInstances'? [Y/n] Y
Removing unnecessary rows ....................................... [FIXED]
Inconsistency in the table 'smb_servicePermissions' for the column
serviceInstanceId: No rows in the table 'smb_serviceInstances' with
id = 429 (2 broken references) .................................... [WARNING]
To see more details, run the command in the verbose mode: plesk repair db -verbose
Remove unnecessary rows from the table 'smb_servicePermissions'? [Y/n] Y
Removing unnecessary rows ....................................... [FIXED]
Inconsistency in the table 'smb_serviceEntryPoints' for the column
servicePermissionId: No rows in the table 'smb_servicePermissions'
with id = 856 ..................................................... [WARNING]
To see more details, run the command in the verbose mode: plesk repair db -verbose
Remove unnecessary rows from the table 'smb_serviceEntryPoints'? [Y/n] Y
Removing unnecessary rows ....................................... [FIXED]
Inconsistency in the table 'smb_serviceEntryPoints' for the column
servicePermissionId: No rows in the table 'smb_servicePermissions'
with id = 857 ..................................................... [WARNING]
To see more details, run the command in the verbose mode: plesk repair db -verbose
Remove unnecessary rows from the table 'smb_serviceEntryPoints'? [Y/n] Y
Removing unnecessary rows ....................................... [FIXED]
