Top 10 Mistakes When Building and Maintaining a Database

#1 Inappropriate Sizing of DB
If you are new to managing SQL Server databases, it is easy to fall into thetrap of using
SQL Server Management Studio to create your database. We all doit. When using SQL
Server Management Studio you have many options you can set,or you can take the
defaults. The mistake many DBAs make when sizing a databaseis to take the default sizing
options. There are two sizing options you need toconsider, initial size and autogrowth.

The initial size is how much space the initial database will take up. Thedefault is 3 MBs for
Data file and 1 MB for the log file. Now these could bethe appropriate size for your
database. However, if your database is expectedto have 300,000 or millions of rows of data
shortly after being created then alarger initial size for data might be appropriate. You need
to determine howmuch space you will need initially and the growth rate of your database to
setthe initial size and growth rate appropriately for your Data file. Sizing thelog file should
also be considered and should be based on how much changeoccurs in your database. If
you are performing lots of inserts and updates thena larger log file will be needed, verses a
database that changes very little.

#2 No Database Backup Plan

The worst thing you can do is not have any backups of your databases. Thenext worse thing
you can do is not testing to see if you can restore yourdatabases from backup. As a DBA, if
you cannot recover your corporate data thenyou had better get your resume out on the
streets, because you most likely willneed to be looking for a new job.

There are three different backup types: full, differential and transactionlogs. In order to
determine which ones to use, and how often they should be rundepends on your backup
requirements. Work with your customers to define theirrecovery point objective and then at
a minimum make sure you have databasebackups to meet their requirements.

You should periodically test restoring databases from these backups just tomake sure they
work. Ideally, you would perform some disaster recovery testingin conjunction with your
customers at a secondary location. However, at aminimum you might want to test the
recovery process on some isolated test box.

Lastly, you might want to consider an alternative storage location for yourbackup files. Do
not just leave them on the server where the databases exist.If that server melts down all
your backups are gone. Make sure you copy yourbackups to an alternative storage location.
That alternative location could beanother machine, tape, or some external storage device.
You might also want toconsider offsite storage for these copies of your database backups.

#3 Poor Security Model

Your best line of defense against security breaches is to have a goodsecurity model. Do not
use the SA account for anything. When you install SQLServer set the SA account password
to something complicated, write it down,store it in a secure location and never use it again,
except in an emergency.SQL Server has two different security models you can use, SQL
Server andWindows Authentication. SQL Server is the least secure. Use these
differentauthentication methods appropriately in your environment.

When you provide access to a database and/or database objects, you shouldonly give
people the kind of access they need to do their job. Do not givedeveloper DBO access in
production, unless it is their job to maintain adatabase. Only allow people to have update
rights to tables if they need tohave that kind of access to do their job.

You also want to develop a security model that is easy to maintain. Considerusing Windows
Groups and Database Roles to help organize your security rules.Using groups and roles
allows you to provide similar access to people by simplydropping them into a Windows
Group or Database role. Organizing access rightsusing group and roles can make security
administration much easier.

#4 Use of Adhoc Queries

Do not allowing applications to submit adhoc queries. When you have adhocqueries, you
have to provide permissions to tables and views in order for theseadhoc queries to run. This
means that users will need to have SELECT, INSERT,UPDATE, and DELETED permissions to
your database tables in order to run theseadhoc queries. This kind of access allows
individuals to write their own codeagainst the database, circumventing using an application
to access and update adatabase.

It is better to encapsulate your application code into stored procedures.This will allow you to
only give users EXECUTE permissions. Doing this meansusers will not be able to access
tables directly outside the applications usingSELECT, INSERT, UPDATE, and DELETE
statements. Additionally, stored procedurescan provide better performance through
compiling and caching the executionplans.

#5 No Data Integrity Rules

Do not rely on your application to enforce all data integrity rules. A SQLServer database can
be designed to enforce some data integrity rules. Takeadvantage of these rules when you
build your database.

If your application requires a given table to have a unique record then makesure you
provide a unique constraint on that table. In addition, if yourbusiness rules say that a
parent record needs to exist prior to creating achild record then make sure you create a
foreign key relationship between theparent table and the primary key of the child table. You
can also provideadditional data integrity by providing default values and check constraints
tomake sure your data matches your application business rules.

#6 No Testing or Limited Testing

It is poor practice to put code into production without testing it. Thisgoes for all changes,
even a small logic change. When you do not test yourcode, you run the risk of it not
working, or more importantly introducingadditional problems.
When building your code it is common practice to run your code against asmall development
database. This provides for faster testing turnaround times,and allows you to use fewer
resources. The down side of this is yourapplication might not scale well. Therefore, prior to
moving a new applicationinto production you should test your application against a
production sizedatabase. This will allow you to find those performance issues you might
haverelated to large tables.

#7 Lack of Monitoring
What happens when you fill a glass of water and you do not watch the levelof the water
while it is filling? The glass will fill up and overflows if youdo not turn off the water in time.
If you do not monitor your database system,you might also fill up your capacity. By not
monitoring your environment, yourun the risk of having poorly performing applications that
will eat up all yourhardware capacity (CPU, I/O, and disk space).

By monitoring your application for poorly performing queries, you canidentify performance
opportunities. These opportunities will allow you tore-write these poorly performing queries
or add additional indexes to optimizethem. By monitoring and tuning up your poorly
performing queries, you reducethe CPU and I/O required by your application.

You do not want your databases to run out of disk space, just like you wouldnot want your
glass of water to overflow. To keep your disk drives from fillingup you need to monitor them
to ensure there is adequate disk space on yourphysical drives. Ideally, you should track the
amount of disk space growth overtime. By doing this you can predict when you will run out
of disk space. Byproactively managing the growth rate, you help minimize the possibility
ofrunning out of disk space.

#8 No Periodic Rebuild or Reorganization of

Indexes
As databases grow, indexes are constantly being updated. This constantupdating makes
indexes grow and split, which leads to index fragmentation. Inorder to optimize your
indexes you need to periodically rebuild or reorganizeyour indexes.

SQL Server provides us with index fragmentation information. You shouldquery this
fragmentation information to determine which indexes should berebuilt or organized. By
periodically rebuilding and reorganizing indexes, youcan improve your application
performance.

#9 No Indexes or Too Many Indexes

Performance of your application is important. Indexes will help yourapplication quickly find
the data they need. Having fast access to the dataprovides your end users with a well
performing application. However, if youhave no indexes or too many indexes your
performance may suffer.

You need to monitor your database for missing indexes, or indexes that arenot being used.
SQL Server provides you with index usage and missing indexinformation. If you find a
missing index that could help a large number ofcommands then you should consider adding
that missing index. Monitoring canalso identify indexes that are never used. These are the
indexes you shouldconsider removing. Be careful when monitoring and removing indexes
becausethese indexes might be only used for monthly, quarterly, or yearly processing.

#10 No Change Management Process

Maintaining a stable production environment is extremely important. Databasechanges need
to be well thought out and planned. Having a change managementprocess provides some
structure around how changes are made.

You need to develop a change management process for your environment.Changes should
be tested in an isolated non-production environment. Once youhave thoroughly tested a
change then you can plan for the productionimplementation. When implementing changes
into production, make sure you have afallback plan just in case your implementation into
production does not go asexpected. By having a change management process, you are able
to document everychange that goes into production, and make sure it goes through the
appropriatetesting process. Doing this well help maintain a stable production environment.