 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / Informix Topics / October 2008identify changes for level 1 backup?
Solaris 10 Sun V480 Informix 10 Sometimes I observe a huge increase in the size of a level 1 archive from one day to the next. That tells me there were some big-time updates going on that day. Is there a way to identify the rows/tables that have been changed since the level 0? In other words, how can I determine the contents of a level 1 archive? Thank you. DG > Solaris 10 > Sun V480 [quoted text clipped - 9 lines] > > DG Level 1 will contain all the pages that were changed since the last level 0. You could see which pages were changed by comparing their timestamp with the timestamp when the backup started. This would imply reading all the pages, so it's a resource intensive task... And since you would need to read them, you might as well write them (in other words, make the level 1). This could lead to a nice feature request... writing the checkpoint timestamp in each chunk/dbspace (internal structure) if any page is written to it... For less used (written) chunks/dbspaces, this could lead to much lower level 1/level 2 backup times... Of course, all the problems associated with the "timestamp" would have to be considered... Regards  SignatureFernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... > Level 1 will contain all the pages that were changed since the last level 0. > You could see which pages were changed by comparing their timestamp with the > timestamp when the backup started. This would imply reading all the pages, so > it's a resource intensive task... And since you would need to read them, you > might as well write them (in other words, make the level 1). Thank you, Mr. Nunes. I do, in fact, make the Level 1 backups. I just am wondering how to identify the what is in them. When I see a sudden, large increase in the size of a Level 1, I would like to know what caused it. (That is, I'd like to identify the changed tables, sorted by the size of their Level 1 deltas.) DG >> Level 1 will contain all the pages that were changed since the last level 0. >> You could see which pages were changed by comparing their timestamp with the [quoted text clipped - 5 lines] > > I do, in fact, make the Level 1 backups. Yes, I got that... > I just am wondering how to identify the what is in them. When I see a > sudden, large increase in the size of a Level 1, I would like to know > what caused it. (That is, I'd like to identify the changed tables, > sorted by the size of their Level 1 deltas.) What I tried to explain is that although it would be possible, You'd have to run a query that would need to read all the pages in the engine. It's the same process the backup uses... The information stored in a level 1 image is useless without the level 0. It's just a bunch of pages that changed since the last level 0. Regards. SignatureFernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... > davidegr...@gmail.com wrote: > > When I see a > > sudden, large increase in the size of a Level 1, I would like to know [quoted text clipped - 6 lines] > The information stored in a level 1 image is useless without the level 0. It's > just a bunch of pages that changed since the last level 0. Thank you. At the risk of beating a dead horse, that kind of info could tell me what tables are being changed. I don't think I really care about what data is actually being changed. For instance, a list of table names, and the number of changed pages foreacht table would, I think, be useful. Regards, DG >> davidegr...@gmail.com wrote: > [quoted text clipped - 19 lines] > > DG Don't worry about the horse... I'm not the best person to explain this, but I'll try. Each page in the instance has a "field" called timestamp. Unfortunately this "timestamp" is not (and could not be) a "human timestamp". You can think about it as an internal clock that ticks every time somethings are changed in the instance. Whenever a level 0 backup starts, the backup utility starts to copy ALL the pages and the timestamp that was current at the begining of the backup is saved. Any page that is changed during the backup get's it's original image copied to the temporary dbspaces. After the end of each dbspace backup, these images are copied to the backup device (this is needed to get a consistent physical image without holding transactions). Now... anytime a page is changed, it's timestamp is changed. The current timestamp get's "stamped" on the page. Whenever a level 1 backup starts, the engine will read the pages, checking if it's timestamp is higher than the one saved when you did the level 0. If it's higher, that page was changed after the level 0 started and as such it needs to be saved into this level 1 backup. Now, you have access to all the pages metadata (timestamp included) through sysmaster views. Theoretically, you could query these views, and read all the pages that contain a timestamp higher than the one saved by the level 0. Why do I say "theoretically"? Because running this query would force the engine to read all the pages (full page, not only metadata). With the page physical address (also included in the metadata of the page), you could find out what partition/table the page belongs to. This is highly resource intensive, and your performance would fall. It would be like doing to backups... Other options you have: . Reset instance statistics at around midnight (onstat -z) . Check what were the partitions more heavily used with things like "onstat -g ppf" (ppf = partition profiles. You'll need TBLSPACE_STATS 1 to use this) This info is also available through sysmaster views This would allow you to see the most used partitions without too much overhead (TBLSPACE_STATS will make the engine work more, but it's acceptable in most situations - I use it everywhere) Please check the manuals for: - TBLSPACE_STATS - onstat -g ppf - sysmaster views Regards. SignatureFernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.