ASM Integrity check failed with PRCT-1225 and PRCT-1011 errors while creating database using DBCA on Exadata 3 node RAC

 

Error:

The error message PRCT-1225: failed to verify Oracle Automatic Storage Management (Oracle ASM) user credentials using the command 'asmcmd credverify' indicates that the asmcmd credverify command failed to verify the Oracle ASM user credentials. This can happen for a number of reasons, including:

• The user credentials are incorrect.
• The user credentials file is corrupted.
• The user does not have the necessary permissions to run the asmcmd credverify command.
• There is a problem with the Oracle ASM instance.

To troubleshoot this error, you can try the following:

1. Make sure that the user credentials are correct. You can do this by trying to log in to the Oracle ASM instance using the same credentials.
2. Check the user credentials file for errors. You can do this by using a text editor to open the file and inspect the contents.
3. Make sure that the user has the necessary permissions to run the asmcmd credverify command. You can do this by checking the user's permissions on the Oracle ASM instance and on the user credentials file.
4. If you are still having problems, try restarting the Oracle ASM instance.
5. If you are still having problems, contact your system administrator for help.

Here are some additional tips for troubleshooting this error:

• If you are using a password file to store the Oracle ASM user credentials, make sure that the file is in the correct format and that it is readable by the Oracle ASM instance.
• If you are using a single sign-on (SSO) solution to manage the Oracle ASM user credentials, make sure that the SSO solution is configured correctly.
• If you are using a cloud-based Oracle ASM instance, make sure that you have the correct permissions to access the instance.

Solution:

$ asmcmd credfix

credfix: Credentials for CRSUSER__ASM_002 not in password file, trying next credential.

op=addcrscreds wrap=/tmp/creds0.xml

credfix: Creating new credentials, no valid credentials in OCR.

credfix: New user CRSUSER__ASM_001 created.

op=credimport wrap=/tmp/creds0.xml olr=true force=true

credfix: OLR for xxxxxx01 has been fixed if credentials were created incorrectly.

credfix: Starting SSH session on node xxxxxxx02.

credfix: OLR for xxxxxxx02 has been fixed if credentials were created incorrectly. Exiting SSH session.

credfix: Starting SSH session on node xxxxxx03.

credfix: OLR for xxxxxxx03 has been fixed if credentials were created incorrectly. Exiting SSH session.

op=delcrscreds crs_user=CRSUSER__ASM_002

credfix: Deleted CRSUSER__ASM_002 from OCR.

credverify: Credentials created correctly on xxxxxx01.

credverify: Starting SSH session on node xxxxxx02

credverify: Credentials created correctly on xxxxxx02. Exiting SSH session.

credverify: Starting SSH session on node xxxxxx03

credverify: Credentials created correctly on xxxxxx03. Exiting SSH session.

credfix: Credentials have been fixed if they were created incorrectly.

Lock Tables in MariaDB

Whether or not you need to lock tables while backing up MariaDB depends on a few factors, including the type of backup you are performing and the tools you are using.

If you are performing a full backup, you should lock the tables to ensure that the backup is consistent. This is because a full backup copies all of the data in the database, including any data that is currently being modified by transactions. If you do not lock the tables, it is possible that the backup could contain inconsistent data.

If you are performing a differential backup or an incremental backup, you may not need to lock the tables. Differential and incremental backups only copy the data that has changed since the previous backup. This means that the data is already consistent, so there is no need to lock the tables.

However, some backup tools may require you to lock the tables, even if you are performing a differential or incremental backup. This is because these tools may need to modify the database in some way in order to perform the backup.

If you are unsure whether or not you need to lock the tables while backing up, you should consult the documentation for the backup tool you are using.

Here are some general recommendations for locking tables while backing up MariaDB:

• If you are performing a full backup, you should lock the tables.
• If you are performing a differential or incremental backup, you may not need to lock the tables, but you should check the documentation for your backup tool to be sure.
• If you are using a third-party backup tool, you should follow the instructions provided by the tool vendor.

Here are some additional things to keep in mind:

• Locking tables can have a negative impact on performance, so it is best to avoid locking tables unless necessary.
• If you do need to lock tables, you should unlock them as soon as you are finished with them.
• If you are unsure about how to lock tables or how this might impact your backup, you should consult with a database administrator.