10 Ways To Destroy A SQL Database - Hungred Dot Com - The Diigo Meta page

• 10 Nov 09
  

  Mr. DiGi

  sql database tips

  • Don’t Monitor Error Log
  • 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.
  • 19 more annotations...
  • • Don’t Fine Tune Queries
    • 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
    • Don’t Document Procedures and Configurations
    • 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’.
    • Don’t Backup
    • Developers or DBA who accidentally deletes data can also be of help. Deleting columns, table, rows, data or even database
    • Don’t Use Memory Wisely
    • Don’t Worry About Indexes
    • Indexes is the most effective way to destroy your database
    • The first one required you to do absolutely nothing. No indexing is required purely full scan table
    • 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
    • Don’t Normalize Your Database Design
    • Skipping normalization can help contribute to bad database design which is part of the plan to destroy a 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 expect
    • Don’t Make Policies For Database Patch
    • If you think that databases are a little more isolated than the desktop, there’s less of a security concern and thinks that your databases are more secure because they’re behind firewalls and and have a good perimeter security, you are on the right track of destroying a database
    • Don’t Bother Caching
    • 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
    • Don’t Use Fast or Reliable Disk
    • With the help of a single disk, you can expect 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 performed 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 as much as 80% compared to RAID-5 which only degrade performance on the faulty disk itself. There are more ‘advantages‘ on RAID-5 but i will just stop here
• 

  alfred westerveld
• 23 Oct 09
  

  Clay lua

  This article is practically showing you how to destroy your own database by doing all the opposite things that should be done correctly. Check out whether you are doing so by reading it.

  10 Ways To Destroy A SQL Database - Hungred Dot Com

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.