Best Practices for your Exchange 2010 Database and Transaction Logs

http://www.Pluralsight.com/Exchange-Server-2010-Backup-and-Recovery-Training.aspx?utm_source=YouTube&utm_medium=Social%20Media&utm_campaign=Best%20Practices%20for%20your%20Exchange%202010%20Database%20and%20Transaction%20Logs

In this demo from Pluralsight's Exchange 2010 Backup & Recovery course J. Peter Bruzzese will who you the best practices to use for your database and transaction logs.

-~-~~-~~~-~~-~-
This channel is an archive! Subscribe to Pluralsight for new IT Pro training
➨ https://www.youtube.com/user/Pluralsight?sub_confirmation=1

-~-~~-~~~-~~-~-

---

Closed Caption:

greetings this is JP tubers easy and
this demo is from my exchange 2010
backup and recovery course it's about
best practice when it comes to your
database and transaction logs so let's
get started
ok so here we are on direct typical and
for starters let's just take a look at
our computer management tool under Disk
Management just to show you that here we
have our C Drive and when we install the
exchange we installed it to see so
everything is on sea including the
database the transaction logs
everything's on the c drive
but here you'll notice we have two
additional volumes we have an M volume
and an R volume now
ultimately these could be additional
discs that you have in the system
these could be attached discs in terms
of a raid array
however you have your server setup in
our case we're dealing with a virtual
server
these are two VHD files virtual disks
that we have set up and we've named the
first 1m and that's for mirror which is
where we're going to put our transaction
logs and the second one is our and
that's where raid5 and that's where
we're going to put our database so these
two are empty there's nothing going on
in there and we're going to now divide
our database to one side and our
transaction logs to the other remember
they're currently residing on see now if
we look at where they're currently
residing you can see you can follow the
whole path through program files and
then microsoft exchange server v14
mailbox and we've got this one called mb
database now initially a database is
named and numbered something along the
lines of mailbox database and then
there's a number after it in our case we
actually change that so that we would
have this database here be our main
database with all of the various
mailboxes inside of it i just prefer to
use mailbox databases that i can name
instead of going with these numbered
ones but this one is still here we
haven't removed it but this is the one
that we're using so here you can see all
the things we talked about when it came
to storage and the storage architecture
we have our existing log that is one
megabyte in size and when that log is
actually filled up it will be renamed as
something else and you can see the logs
just grow and grow and grow at the same
time if we move up here you can see the
checkpoint file here and if we move down
here is the database itself and be
database that Ed be so it's all in one
spot and it's all on the C Drive
definitely not best practice what we
want to do is we want to move the
database to the r dr we want to move our
transaction logs to the M drive now the
way to do that through the exchange
management console and you can use the
exchange management shell as well it's
just easier to do through the console
here under organization configuration we
have the mailbox node here we see the mb
database if you just right-click on it
and choose move data base path you'll
notice that it gives you the option to
move the path off of see something else
so here we recall we're going to move
the mb database
to the our drive and we're going to move
the mb database transaction logs to the
M drive
and the only thing you'll notice here is
that we see it says mb database that's
actually the folder path we're actually
going to add a folder path in here as
well and will click move
and the reason we added that folder in
is because the exchange database file
cannot be placed at the root of any
drive so it has to be in a folder and
that's just a rule so make sure you put
in a folder named if not it will just
give you an error message and you can go
back and add in the folder now here it
says in order to perform the operation
it has to temporarily dismount the mb
database we say ok that's fine we see us
to all
and there we go it's complete we click
finish
it refreshes the screen it shows us that
it's mounted again and here if we now go
into the information here look you see
things have changed and all of our stuff
is gone well okay let's just take a look
at where it went
if we go to the M drive here we see the
movie database there's those logs it
move those over we go over here and be
database and there's our database file
now we're following best practices we
have this database on a virtual raid
which is running as volume are and we
have our transaction logs on a virtual
mirror which is running as m and so
obviously in every situation you might
have that different it might be
different drive letters and so on but
now we have everything off of the system
drive and the driver exchanges installed
and we have these on two separate drives
in the event this database needed to be
restored from a backup because let's say
it was corrupt or the disc failed or
whatever the transaction logs from the
other disk would allow themselves to be
replayed into the newly restored
database and you're as up-to-date as the
last transaction log that came in so
that's really best practice for your
recovery is to separate those two and so
hopefully this showed a very simple way
to do that so now let's talk a little
bit about deleted item retention times
let's go back over to our exchange
management console and if we right click
on the database itself and go to
properties
and then if we take a look at limits you
can see here the deletion settings for
that database and it's established on a
database by database limit so you can
have databases have different deleted
retention times in this case the keep
deleted items for days the default is 14
and keep deleted mailboxes four days is
30 and you can say don't permanently
delete items until the database has been
backed up so that's actually something
you might want to turn on if you're
concerned that items will be deleted
before backup now why would that take
place
well it depends on when you do backups
if you're not doing regular backups then
those items might be deleted permanently
and perhaps there's never been a record
of them in the back up so you can select
this little checkbox to assist you in
that oftentimes however you have a daily
backup or hopefully a daily backup and
that will prevent the need for this
checkbox to be selected at all because
you will get a backup of all the items
so now that you can see the deleted
retention times
let's focus on the first one the deleted
items so 14 days a user can delete an
item and delete it even from their
deleted items folder it's gone and they
can still bring it back to life now
maybe you've heard of this but you
haven't seen it in action before
well that's okay you can't know
everything so let's jump over to our
client system and let's just show you
how this would work for a user that
delete something permanently from their
deleted items
thanks for watching for more information
regarding our training please visit
www.renaissancecapital.com