Uncategorized

Quote

25 Things I Wish You Knew About Databases

  1. Oracle will do what you tell it to do. I find that PEBCAK is often the root cause for many issues.
  2. DBAs get paid for performance, but we keep our jobs with recovery.
  3. HA <> DR. If you can’t recover, you can’t keep your job. See previous item.
  4. Memory, CPU, disk, and network are all finite resources. Leave room for growth.
  5. 95% of all workloads will run just fine on modest hardware. Don’t listen to fools that architect crazy solutions for edge cases that won’t happen.
  6. Backups. You need them. Store them someplace safe, and on a different server. See number 2.
  7. Maintenance is mandatory. Find, or make a maintenance window.
  8. But you can always blame the network anyway 🙂
  9. Know the RTO and RPO for your applications. See number 2.
  10. Focus on wait events and logical I/O when performance tuning. They help you find the root cause the fastest.
  11. The only way to know your backup succeeded is to test by doing a restore. See number 2.
  12. Build a recovery strategy BEFORE you build a backup strategy. See number 2.
  13. Baseline for performance. Without baselines and metrics you have no idea if something is truly a problem or not.
  14. Keep your transactions short.
  15. Triggers are awful, awful little creatures.
  16. But NULLs are far worse.
  17. If your DBA can’t work a command line, don’t let them touch your data.
  18. Great database performance starts with great database design.
  19. Deadlocks are often the result of application logic and data access patterns. The engine doesn’t just get “tired” and start deadlocking.
  20. Testing against 10, 100, and 1000 rows is not an accurate test against a production workload.
  21. Application code is responsible for 100% of all performance issues. #hardtruth
  22. Keep as many of your servers configured in the exact same way. This saves time troubleshooting.
  23. Data lasts longer than code. Treat it right.
  24. Don’t install services (SSRS, SSIS, SSAS) onto a server “just in case”. Only install the services that are needed.
  25. If your vendor requires the use of the ‘sa’ account, go find another vendor.
Aside

Genesis of a DBA Universe

In the beginning was the disk array, and all was empty and raw, and Unix moved over the face of the platters. And the DBA said: Let there be Oracle. And there was Oracle. And the environmental variables were set and the disks were striped and mirrored and the OFA was established, and behold spindle was rent asunder from spindle. And the DBA saw that all was in spec.

And it was day and it was evening of the first day.

And the DBA said: Let there be scripts. And sql.bsq brought forth myriad crawling things upon the face of the array. And catalog.sql brought forth all manner of tables and views that swim unseen beneath the waters. And catproc.sql brought forth all the built-in programs and all the hosts of the air, that the users might be given wings and take fight over the data.

And it was day and it was evening of the second day.

And the DBA said: Let there be tablespaces. And there were tablespaces. And the network administrator looked upon the disk array and did see what the tablespaces had wrought upon the disk arrays, and he did gnash his teeth and seek a new work upon the Internet with an engine of search.

And it was day and it was evening of the third day.

And the DBA created users. Male and female he created them. And he said unto the users: Thou mayest create tables and views as thou wilt. Yea, though mayest create even indexes upon the data. Only meddle not with the system tablespace, for it is a holy place, and on the day wherein thou treadest upon it, on that day thy create session shall surely be revoked. And the serpent crept among the users and whispered to them, saying: Thine roles shall not be revoked. Taste ye all of the system tablespace, for ye shall know of b-trees and hints and ye shall be as DBAs. And the users heeded the serpent and filled the system tablespace with crap. And the instance did crash and the client did wax wroth at the DBA. And the DBA did gnash his teeth and partake of the fruit of the vine, for behold the users were permanent employees and the DBA was but a contractor and could not revoke their create session.

And it was day and it was evening of the fourth day.

And the DBA did set default tablespaces and temporary tablespaces and did lock down all that was upon the face of the array with roles and profiles and all manner of quotas, yea even from the rollback segments even unto the archived redo logs.

And it was day and it was evening of the fifth day.

And the DBA created synonyms and links and did tune the server and apply patches upon the face of the database.

And it was day and it was evening of the sixth day.

And on the seventh day the DBA did rest from all the labors of the creation. And his pager did ring and he ceased from resting and did spend his sabbath on the telephone with Oracle support. And by the time the DBA got through to someone who knew whereof they spake behold it was day and it was evening of the eighth day.

And the DBA waxed wroth.

Deferred Segment Creation

Property Description
Parameter type Boolean
Default value true
Modifiable ALTER SESSION, ALTER SYSTEM
Range of values true | false
Basic No

DEFERRED_SEGMENT_CREATION specifies the semantics of deferred segment creation. The design goal here is to prevent hundreds or thousands of segments being created by a 3rd party application that only uses a few of the tables it creates. If set to true, then segments for tables and their dependent objects (LOBs, indexes) will not be created until the first row is inserted into the table. Before creating a set of tables (or installing an application), if it is known that a significant number of them will not be populated, then consider setting this parameter to true. This saves disk space and minimises install time. This feature was first introduced in 11g.

Deferred segment creation allows tables and indexes to be created without physical segments which can be a double-edged sword as it allows objects to be created even if there is no space available for those objects in the specified tablespace. The data dictionary contains the object information so a query of DBA_TABLES, DBA_INDEXES or any of the %TAB% and %IND% tables and views will return the expected information. Querying DBA_SEGMENTS, however, may fail to return data since an object may not have any segments associated with it.

You should note that you can change this default behaviour (i.e. turn off deferred segment creation) by either:
  • at the database level via your init/spfile
  • at the session level via “alter session set deferred_segment_creation = false;”
  • statement by statement via “create table t ( x int ) segment creation immediate;”

Should you use deferred segment creation? That choice is one both the DBA team and development team need to make. Look at all aspects of the argument then decide accordingly. Remember that the ‘right’ answer is the one that’s suited to your environment.

Aside

12 Days of Denormalization

On the first day of denormalization, my design gave to me
a really fast-running query.

On the second day of denormalization, my design gave to me
2 less tables.

On the third day of denormalization, my design gave to me
3 more indexes.

On the fourth day of denormalization, my design gave to me
4 larger disks.

On the fifth day of denormalization, my design gave to me
5 brand new reqs.

On the sixth day of denormalization, my design gave to me
6 times the locking.

On the seventh day of denormalization, my design gave to me
7 longer updates.

On the eighth day of denormalization, my design gave to me
8 more requirements.

On the ninth day of denormalization, my design gave to me
9 invalid rows.

On the tenth day of denormalization, my design gave to me
10 delays deleting.

On the eleventh day of denormalization, my design gave to me
11 questionable queries.

On the twelfth day of denormalization, my design gave to me
12 lessons learned.

Link

How Is Writing Lord Of The Rings Like Writing Software?

This post originally appeared on HighScalability.com

Have you ever read a book and wondered how any human could have written something so brilliant? For me it was Lord of the Rings. I despaired that in a hundred lifetimes I could never write a book so rich, so deep, so beautiful. Since then I’ve learned a few things about about how LoTr was created that has made me reconsider. The kick-in-the-head is that it’s the same lesson I learned long ago about writing software.

I’ve always been amazed how a program can start as a single source file and after years of continued effort turn into a working system that is so large no human can come close to understanding it. If you had tried from the start to build the system you ended up with you would have never ever got there. That’s just not how it works. Software is path dependent.

I’ve experienced this growth from a single cell to a Cambrian explosion many times so I know it’s a thing. What I hadn’t considered is how it’s also a thing for writing books too.

Creating good software is a process of evolution through the mechanism of constant iteration for the purpose of survival. This is also how good stories are made. What both have in common is creation through thought.

Thought needs an object to contemplate. Each intermediate state of a project is that object. By linking together a series of state inspired creative jumps something wonderful can be created that may contain only the faintest trace of its beginnings.

Here’s how Lord of the Rings is a good example of this process…

Continue reading →