![]() So techncally we should be able to reduce it by 29gb right, but I can only reduce it by 21gb, so really an unload/reload should come down to approx 102 gb. He is likely to find that the database is able to be reduced by a lot more than 60gb. Let's imagine that Aaron's database is performing really poorly, backups are slow due to write times to the db, the selects of the database are all very slow etc and he decides that this db needs an unload/reload. According to those figures there are 15184541 pages available (or appox 60,000 mb). TSM will write to the end of the database is there are no pages usable in the middle of the database. that 20gb is not lost and can be fully utilized. In the unload/reload process you will move all the pages that contain data to the "front" of the database and you will be able to now reduce your TSM Server.Įven in Aaron's example. You will usually find that simple select statements such as on the events and summary table can take an unusually long time to return, this is usually a good indication that something is wrong and needs further investigate. When a database is "dirty" (for want of another word) then I guess the easiest way to describe it is that there are pages that are unusable, but they do not contain data. This is because you still have meta data for other nodes backups at the end of your server, however your server will be completely function in this state and you will not expect to have any noticeable performance hits. You may find your server has gone from 90% utilized to 30% utilized, yet you have no ability to reduce the server. Let's imagine you now decide that is a stupid idea and you stop the archives and after creating another node for the server using a more reasonable approach, you decide that after 14 days you can delete the old node entirely. Now is that obviously that (and other data) is continually added to the end of the database. You database will obviously grow out of hand suddenly, no surprises there. Imagine for a second that someone has 10,000,000 files and thinks it would be a good idea to do a daily archive of this and keep for 90 days. My understanding is that when you reduce it, like adding it, you are taking space from the end of the database. That is when you need to do an unload/reload of your server.Ī TSM database will also shrink depending on what is at the end of your database. TSM is designed to work fine in this situation, the problem lies when your free space in your database is not usable. ![]() I reckon there is a bit of information that I see differently.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |