Error 1033 received logging on to the standby

It seems very simple answer should be to that error which you could see in the primary database alert log file - just synchronize orapw files between primary and standby. But... 

In my case it wasn't so :) 

The answer laid in the interesting detail. The primary was located on filesystem, the standby on ASM. After creation of standby DB the names of redo log files (including names of standby redo logs) stayed as it were on the primary (names according mount points). The primary tried to establish a link to standby redo log files, but because they did not reinitialized (and not renamed accordingly) on standby site, the primary DB failed to transform the transactions content to standby redo log and such meaning :) error was arisen. 

The solution - rename and initialize your standby redo logs or try use different transport (ARCH).

Good Luck !

SEVERE: Connection details provided as OMS_HOST and EM_UPLOAD_PORT is not active when installing OEM agent in silent mode

Recently I stuck into this issue, and the solution was not provide FQDN of OMS server in the response file (parameter OMS_HOST). It turned out that agent installer try to resolve it adding the domain name to FQDN. The installation performed by agentpush method from OMS server.

Worse to note, that agentpush operation from agent host (via emcli) do not throw such error when OMS_HOST=FQDN_of_OMS. So take care about it ! :)

Another case of ORA-01756 error

In sqlplus, when using exec builtin instead of begin...end for running PL/SQL, you may encounter such error when perl quoting mechanism is used (q'{...}' for example) and there are new lines inside the 'execute immediate' command called from PL/SQL block (length of 'execute immediate' is too long). To overcome, use begin...end construction instead of exec.

Good Luck