A letter to Oracle DBA (online spread)

1. Database availability, DBA says "not counted"-materialized view, faster query speed

At some point, the availability of the database is not set by the DBA. Because even if the DBA has absolute control over the database, users may feel differently from their own work and application perspective than the DBA.

What they want is speed! Very simple truth, maybe you have met. One day when you are busy on the job. At the same time, your boss is looking at the company's earnings and has an app on his computer with a button that allows you to see the results of the month or even the current year with just a few clicks. When he ordered it, the result didn't come back at his expected time, so he picked up the phone and called you and asked why the database was "crashed"!

This makes you confused, as if he is not talking about the database you are in front of you! Sometimes there is a problem with a well-set library. We have this problem, and we can also create materialized views only if the table that the boss is currently using is redesigned.

2.　　　　　　They care about the cost! --Have to move and act cautiously

Sometimes the company may need to replace the operating system for cost or development needs, and the data on the original database to import the new database is what we often have to do. The company is very valued for its cost! For terabytes of databases, exp/imp is too old and slow, DPEXP/DPIMP has limitations on versions, and cross-platform tablespace migrations are partially imperfect. Choose what kind of data migration scheme and we have to be cautious!

3. Planned resource allocation--service also has priority, select RAC

Company departments may be less balanced when using database resources. Sometimes there is a high level of time and regularity, which requires that you make the appropriate changes to the DBA! Rational Allocation of resources! The financial year and the end of the month will be settled, development testing will be irregular entry and so on. This requires a service-as-a-priority, choosing to assign workloads and system resources. RAC one is a good choice to combine services with RAC, and different services to access different number of nodes. For a large business, it is not in the hate.

4. Downtime and downtime

Sometimes the force majeure factor also needs the DBA to consider. Perhaps just as you are in the dream, the attendant call, the company room leaking, the server is all hung up. In this case who listens to the head is big. You try to call the system administrator and ask if the previous phase of the obsolete server is available, and run back to the company to see if the offsite backup is intact. Maybe it's not your fault, but it can't be solved, it's your fault.

Needless to say, clustering and standby are your best options. How important it is for the 7x24. DG, in particular, is the best solution for you to dispense with the human irresistible disaster!

5. Bad blocks can't stop you.

Sometimes you will be informed by the database of bad blocks, then Rman is your best tool, God bless you to make a backup. If you are missing or storage relative areas are unusable, waiting to restore from tape is your only option, provided you have such an insurance mechanism! But if only the user mistakenly operation, the use of flash back is no better!

6. Lack of space, load balancing in hotspot areas

You have an important tablespace that is being used all the time, he is big and big, and the LUN that corresponds to your storage cannot accommodate him, then how do you deal with it! Of course, for log files we can remove it to implement. But what about data files? ASM I thought you'd think that he would automatically balance file load and I/O distribution. Support for adding new disks online to ASM Disk Group!

7. Wrong Operation DBA Nightmare

Early in the morning a bad egg, bleary sitting in front of the db, for the daily maintenance work, suddenly when a humble finger hit the keyboard, he no longer sleepy. An incorrect carriage return, deleting part of a record of an important table. This happens in our actual work countless times, how to do! Sober he thought of the use of incomplete recovery, to recover the mistake! But none of this has been seen, and if not fully restored, it means that the application for downtime, the leadership of the transformation .... It's horrible! Actually, flashback gives you the opportunity: row-level recovery with flashback. Things are destined to be together, in front of the unlucky egg rocky, the telephone rang. The phone is from the finance department, meaning that because of the mistake, he changed the financial software to the salary scale of a salary increase of a wrong number, you find that your monthly salary has become million (jokes). In fact, everyone is so expected! It needs you to save his mistakes! Using flashback can also help you solve problems quickly.

8. Be a good habit of DBA

Sometimes you will find your udump under the trace file skyrocket, most of the time he is caused by your carelessness, to close those unnecessary sql_trace, you will always remember how deadly such errors are for a production library!

A letter to Oracle DBA (online spread)