10 ways to destroy a SQL database

Database is the asset of most online or Internet based company.
Everyone looks at how to improve and secure their databases to protect
Or improve their company. While everyone is searching for remedies or
Enhancement pills for their company, there are often simple mistakes
Made by some companies (especially the small to middle ones) that might
Just destroy their businesses. Rather than looking at how we can protect
Our database, this article will look at ways to destroy it instead!
(Through mistake, of course)

Don't monitor Error Log

The first line of defense that any database wowould have. Error Log may
Indicates first time problem occurs or warnings that your database
Might be facing problem. These troubles can be easily avoided or missed
Depending on what you do. Be my guest and ignore error log will
Definitely help to destroy your database.

Specified company databases are designed in a way to enforce availability.
Hence, there will surely be primary and slaves databases in such
Company. These databases also contain error files. However, if you wowould
Like your secondary databases or slave databases go out of sync
The primary database, be sure to ignore the error file and give it some
Time. Depending on the size of your company, the amount of data lost
Caused by the lost of synchronization might just cost you dearly when
Some hero DBA shutdown the primary database without issuing "Stop slave"
First on the slave database or wait till some errant SQL come down
Line. Although this might take some times to destroy your database
Its worth to think about using it.

Don't fine tune queries

You have a big server, lots of memory and fast disk, so don't have
Worry. Continue with this attitude and you are on your way to success
(Destroy it !). Developers writing bad code that caused full table Scan
And trying their best to trash your query cache, overloading your InnoDB
Buffer cache with useless blocks. Plus hitting disk instead of main
Memory as much as possible? Well, there won't be any problem since every
Piece of hardware is the latest, fastest and most powerful ones! Let's
Just wait and see till your database fall on its knees! Especially when
Data is getting larger! That's the best time we see this happen!

Don't document procedures and tolerations

Ah! No documentation won't cause a single problem! No problem at all
My friend! Why the need to enforce such tedious job when 'we' can
Maintain the job? Just you wait when the 'we 'becomes' I 'and' I'
Becomes 'who '. employees come and go nowadays. People always look for
Better Future in life and no matter what happens to you, it's really
None of their concern. Man! What so difficult? Let's just hire an expert
To take the job. Oh boy! That's a great solution! Let's see when he
Presses the wrong button

Don't backup

Another great way to destroy your database is to avoid making
Backups! Hardware failure is a common thing in Data Center. Hard Disk
Fail, power supply down, plugs get pulled, basically anything you can
Imagine. Don't backup regularly can just do the thing!

Its not only hardware that might assist you in your task. Developers
Or DBA who accidentally deletes data can also be of help. Deleting
Columns, table, rows, data or even database! These sort of things do
Happen and it happens quite frequently. Other than deleting data,
Mistakes made on program might just transfer the wrong data to the wrong
Place. All of these are just things that might happen to any IT firms.
Well, there is always never happen before situation for some of you.
Just follow your instinct (Backup suck !) On this and you will do just
Fine.

Don't use memory wisely

Server nowadays have huge memory installed with it. Technology
Advancement has made everything more powerful than before. Furthermore,
It is that affordable that cannot companies can afford big and fast
Memory! With such powerful memory backup, we can assure that whatever
Developers throw in, the server and database will surely be able to take
It! We can safely assume MySQL knows our database memory requirement!
We just have to run the wizard installation and Viola! Everything is
Automatic nowadays! There won't be such thing as misallocation
Memory. The system is perfect.

Good to know. You have everything that required (even attitude) in preparing to bomb up your database.

Don't worry about Indexes

Indexes is the most valid way to destroy your database. However,
You must know the trick to do this. There are two ways to succeed.
First one required you to do absolutely nothing. No indexing is required
Purely full scan table. However, this required certain criteria to be
Meet but it shoshould do the trick. If this doesn't suit your taste, you
Can try a faster way by creating useless or unwanted indexes and ensure
That your table have tons of records. This can surely improve
Process of destroying your database.

Don't normalize your database design

If you are just starting to build a system, you can consider skipping
Normalization in your database design. Skipping normalization can help
Contribute to bad database design which is part of the plan to destroy
Database. Furthermore, without normalization, there is a good chance
Your system can be inaccurate, slow, and inefficient, and it might not
Even produce the data you provided CT.

Don't make policies for database patch

Its true that majority company doesn't update their databases
Immediately after a new security vulnerability patch has been released.
It wocould be irresponsible for a company to deploy a patch in Production
Without first running it through quality assurance. Furthermore, some
Companies didn't event bother to have policies to update their database.
If you think that databases are a little more isolated than
Desktop, there's less of a security concern and thinks that your
Databases are more secure because they're behind firewalland and have
Good perimeter security, you are on the right track of destroying a database.

Don't bother caching

My database can take tons of crap anything throw towards it. Its
Fastest computer (why bother to have technology advancement when we
Already have the fastest? DOT) on the planet. cache or no cache won't
Destroy my database. Its the fastest (Ya, I get it .).
The dramatics performance gain Using Cache table might not interest you.
Scalability, flexibility, availability and performance are just some
Benefits that caching can gives. multitier architecture,
What bullshit. Your server will never go down and you will never
Required cache table to be available. Millions of hits on the server
Database might just do the trick on helping you achieve what you want in
This article. It will definitely work better when your table has few
Millions record and a few lousy queries. (It might not even required
Millions of hit to kill it)

Don't use fast or reliable Disk

Using something like a single disk or mirror will definitely makes
Your I/O the main bottleneck on your system. With the help of a single
Disk, you can perform ct OS and your database fighting for resources,
Serving one user at a time while others waiting for their turn. To make
Things worst, you can try utilize raid-5 instead of RAID-10. May be you
Already are! Well, to compare between these two, raid-5 only
Saved med reasonably well on read while raid-10 exceed almost two times better than RAID-5 on writes. Raid-5 only can handle 1 fails and any drive die will approximately caused 64% degration
In read performance until the faulty drive is discovered. Furthermore
During recovery, read performance for a RAID5 array is degraded by
Much as 80% compared to raid-5 which only degrade performance on
Faulty disk itself. there are more 'tagtages' on RAID-5 but I will just stop here. raid-5 seems to be good with destroying than RAID-10 don't you think so?

Conclusion

The points discuss here might just happen to large data or traffic
Internet site (well, your site will eventually grow to have big data,
Hopefully). However, the conclusion to all these jokes are more
Valuable; learn to save your ass. No one will.

Orginal URL: http://hungred.com/useful-information/ways-destroy-sql-database/