Académique Documents
Professionnel Documents
Culture Documents
#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.
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.
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.
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.
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.
#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.
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.
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.
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.