ORA-22804: remote operations not permitted on object tables or User-defined type columns
Restriction on Using User-Defined Types with a Remote Database:
One of my application team lead called me... Raja, we have faced DB link issue while accessing the table from remote database.
“While accessing the table from remote database & they got the below error”
ERROR at line 1: ORA-22804: remote operations not permitted on object tables or
User-defined type columns
I have verified the database link & its working fine.
Colored SQL in AWR report:
AWR captured all the SQL which was running in database?
MMON captured only top resource consumed queries based on
STATISTICS_LEVEL parameter and dbms_workload_repository.modify_snapshot_settings topnsql variable value.
I want to capture some sql in AWR report.
CONVERTING PHYSICAL STANDBY DATABASE TO SNAPSHOT STANDBY DATABASE
Step 1: Check if Flashback is enabled.
Oracle Grid Infrastructure 220.127.116.11 has many features including Cluster Node Membership, Cluster Resource Management and Cluster Resources monitoring. One of the key area where DBA need to have expert knowledge on how the cluster node membership works and how the cluster decides to take out node should there be a heart beat network, voting disk or node specific issues. I have written about this before and this article specifically focuses on the 11g R2 features and I will also try to explain the reboot less node fencing.
Steps to create standby database using RMAN:
primary database name:taurus
standby database name:taurus
-force logging is enabled on the primary database.
-password file is created for primary database
-primary database is in archivelog mode
SQL> select name,open_mode,log_mode
2 from v$database;
NAME OPEN_MODE LOG_MODE
--------- ---------- ------------
TAURUS READ WRITE ARCHIVELOG
SQL> select instance_name,
The Rule engine is one of the critical pieces in an auditing solution. It sits between the data collection and the reporting output. It is the heart of the functionality that will take the job of reviewing the reports from impossible to manageable to easy. The reason it is so important is the vast amount of SQLs that go through a database engine. A good rule engine will reduce the amount of SQLs in the report and increase their relevance.
Change control is an important part of being compliant. You will not pass an audit without having a change control process in place. One of the requirements you might face is to monitor all changes in the database and make sure they all came from the change control process.
Blue Core Research's "NO BULL" buyers guide to Database Auditing products - Part 13: Application user IdentificationSubmitted by tduong on Mon, 2010-11-08 22:23
There is a common misconception about the value of application user identification. The reason for the misconception is the marketing of this feature by some companies, but we'll get into all that later. First lets examine the idea.
Most applications have a single database user that they use to access the data. To enforce security, these applications maintain an internal list of users and roles that they enforce. In other words – instead of using the database security features, that functionality is performed by the application. The result is that when you look at the database activity you see everything coming from a single user. An obvious requirement is to map the database activity to the application user as it is seen by the application.
Simple introduction to Oracle Database 11g Rules Manager using good old EMP table.
This Article introduces Oracle Rules Manager in a series of simple examples with imaginary cases on the EMP table. This article is an overview of the possibilities of Oracle Rule Manager for a traditional Oracle Architect who has never thought of a Rule based approach. It will also be informative to communities working actively with other Rule Engines, who never considered the Oracle Rule Manager.
Blue Core Research's "NO BULL" buyers guide to Database Auditing products - Part 14: Oracle and MS SQL ServerSubmitted by tduong on Fri, 2010-10-29 00:59
Most companies have more than one database vendor. Oracle, SQL Server, DB2, MySQL and Sybase are all common depending on the company, and some use less common databases such as TeraData. There are, however, some important questions to ask before you dive into your cross platform heterogeneous requirements:
* Which databases do you actually need to audit? Is all your SOX, PCI, HIPAA or other sensitive data scattered across all these databases, or is your SQL Server just used for small home-grown apps that do not have any auditing requirements?
* Do you have the same DBA or team managing all these databases, or are they different teams that will end up managing auditing solutions independently? In the later case you are better off choosing the best solution for each database rather than mandating a single solution no one is too happy with.