ORA-01013: user requested cancel of current operation

If ORA-01013 appears in the alert log file, it would mean that your application is closing a session forcefully and database records this as action canceled by the user/application (as name description of this error suggests). It would mean that most of the time it is not something that can be handled from the database side to stop this message from appearing in the alert log file. But, sometimes this error may be because Oracle internally kills some process that crosses a timeline already defined. In the following I would provide further detail of this.

Error 12154 received logging on to the standby

There are several error messages related to dataguard environment and many of them have been discussed in my blog, and you can find links to those articles at the bottom of this article. In this article, I will explain Error 12154 that I received in one of my dataguard environments. This error message may appear in the alert log file of your primary database and it would seem similar to the following.

Error 12154 received logging on to the standby FAL[client, USER]: Error 12154 connecting to <FAL_SERVER> for fetching gap sequence

Error 1033 received logging on to the standby

Troubleshooting a dataguard environment is not very straightforward sometimes. If you come to know that physical standby database is out of sync with the primary database, first thing is to check the alert log files of primary and standby database to find out any error messages that might be appearing in the alert log files. For example, if error 1003 is reported in the alert log file, you may see entries similar to the following in the primary database’s alert log file.

Mon Feb 06 00:10:40 2017 Error 1033 received logging on to the standby PING[ARC1]: Heartbeat failed to connect to standby 'MY_STANDBY_DB'. Error is 1033.

Starting and Stopping Grid Infrastructure on a Standalone GI Installation

This document explains how to start and stop an Oracle cluster. To start and stop Grid Infrastructure services for a standalone installation, there are slightly different commands. Using same commands as RAC to start and stop the GI resources would return errors as follows

[root@~]$ /u01/app/11203/grid/bin/crsctl stop crs CRS-4013: This command is not supported in a single-node configuration. CRS-4000: Command Stop failed, or completed with errors. [root@ ~]$ /u01/app/11203/grid/bin/crsctl stop cluster -all CRS-4013: This command is not supported in a single-node configuration. CRS-4000: Command Stop failed, or completed with errors.