|
May, 2004
In
This Issue
|
|
All articles have been reprinted with the written consent of their respective authors. | ||||||||||||||||
|
||||||||||||||||
|
BUGBUSTER - V$SQL_PLAN causes ORA-07445
Symptoms Using a WHERE clause on queries against the V$SQL_PLAN table causes sessions to disconnect.
A glance in the alert.log shows an ORA-07445 error and a trace file left in user_dump_dest. Here is an extract from the trace file:
Workaround You can workaround this problem by creating a temporary version of the V$SQL_PLAN table and excluding the FILTER_PREDICATES column which is a VARCHAR2(4000). Cut and paste the code provided and use the temporary table SQL_PLAN_FIX in place of V$SQL_PLAN. Click Here
for the script. |
||||||||||||||||
|
||||||||||||||||
|
9i RAC: Cloning to a Single Instance
Cloning is a process that most DBA’s are aware of that needs to be done often to keep the production database from being vandalized by then developers and UAT’s. A production database needs to be cloned to test or development or training databases, so that the Application development and any customization can be tested and validated, before porting to production. User acceptance tests are not done and signed off after you go production, but by testing on a copy or clone of production at a point in time. Some sites need to clone often where data integrity and validation is important, whereas others need to be cloned once in few weeks. Either way, cloning is done to test upgrades or when patches are tested on a production copy before applying it to production. So, knowledge of cloning process is a must in any DBA’s job profile.
In this paper we are going to look at one of the important administration jobs, the cloning of a 9i RAC. We will look at how we could clone a 9iRAC database which can have any number of nodes (4 is the limit I think on Solaris and depends on the OS and cluster volume managers) to a single instance. When I say a single instance, it is still going to be a single 9iRAC instance for a RAC database and not a non-RAC database. To down grade after a clone, look up the downgrade document in Metalink.
Click Here
for the article.
Fine-Grained Auditing for Real-World Problems
Traditional Oracle Database auditing options let you track the actions users perform on objects at the macro level—for example, if you audit for SELECT statements on a table, you can track who selected data from the table. However, you don't know what they selected. With data-manipulating statements— such as INSERT, UPDATE, or DELETE—you can capture any changes by using triggers or by using the Oracle LogMiner utility to analyze the archived logs. Because simple SELECT statements are non-data-manipulating, they neither fire a trigger nor go into archived logs that you can mine later, so these two techniques fall short where SELECT statements are concerned. Oracle9i Database introduced a new feature called fine-grained auditing (FGA), which changed all that. This feature lets you audit individual SELECT statements along with exact statements issued by users. In addition to simply tracking statements, FGA provides a way to simulate a trigger for SELECT statements by executing a code whenever a user selects a particular set of data. In this three-part series of articles, I'll explain how you can use FGA for solving real-life problems. This first installment focuses on building a basic FGA system. Click Here for the article.
Note: This article was previously published on OTN
. |
||||||||||||||||
|
||||||||||||||||
|
Basic Performance Tuning Part 2 If you read the first installment of this Distribued DBA column, you know that database performance problems typically arise from one of the following factors:
In the previous column, I covered some general tuning guidelines and described how registry variables can be used to tune DB2 Universal Database (UDB) version 8.1 for Linux, Unix, and Windows at the system level. (Please note the correction regarding two of the registry variables on this page.) In this column, I'll explain the instance and database configuration parameters available with DB2 UDB, plus the Configuration Advisor tool new to v.8.1. Click Here
for the article. |
||||||||||||||||
|
||||||||||||||||
|
Transaction, Heal Thyself!
Part 4 Oracle 9i introduces a long awaited feature that suspends certain transactions instead of failing them straight away. In this series of articles Darryl presents a methodology to take advantage of resumable transactions to support sophisticated transaction processing requirements. Part IV imparts more details of his custom built solution for handling objects exceeding their maximum extent allotment.
This article was originally published in the October, 2003 issue of Oracle
Professional. Click Here for the paper.
|
||||||||||||||||
|
||||||||||||||||
|
How to Make Sure You Have Good Passwords
As many articles have covered SQL passwords are very easy to figure out. SQL passwords are stored in the sysxlogins table in master database. To access this table you have to be a member of the fixed role sysadmin or
sysadministrator. Still there are programs out there that use the lack of SQL accounts lockout to hack a password. What can we do to prevent this or at least make it harder for them?
Click
here for the article. |
||||||||||||||||
|
||||||||||||||||
Assumptions are very much related to risk, and, in fact are simply low-level risks. Let's take an example of a common statement that is included in many Project Definitions – that “the resources needed for this project will be available when needed.” What kind of a statement is this? Most people would say it is an assumption. After all, when a project starts, you always assume you will get the resources you need.
Click here
for more on | ||||||||||||||||
|
||||||||||||||||
|
Free Webcasts
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
||||||||||||||||
|
Interactive Crossword
Puzzle: "Name That Dog"
|
||||||||||||||||
|
||||||||||||||||
|
We love getting white papers, tips, articles, and code examples/archives from our readers around the world. Send your submission to newsletter@quest-pipelines.com. If your article is published, it will be mailed to over 28,000 subscribers. Our mission at Quest Software - RevealNet Labs is to anticipate the daily responsibilities and challenges faced by database professionals. Our products help thousands of people solve problems and implement solutions every day. This newsletter is designed to help facilitate the sharing of information among database professionals. About the Newsletter This newsletter is distributed to Quest Software - RevealNet Labs customers, prospects and friends who have subscribed to it from our website. If you would like to unsubscribe, please visit http://qlist01.quest.com/UnsubMailingList/ Subscribe a Friend! Do you know someone who would like to receive the Pipeline Newsletter? If so, please enter their email address in the box below and click SUBMIT.
Past Issues of the Pipeline Newsletter |
||||||||||||||||
