To address this fear and uncertainty, IBM has recently made a no-charge, downloadable tool available to help customers better estimate the amount of overhead that journaling would add to their system. The toolset, known as Pseudo Journal, can be downloaded along with an installation guide and tutorial.
The Pseudo Journal toolset enables you to have i5/OS monitor changes (inserts, updates, and deletes) made to your database objects. After monitoring your database activity, the toolset can be used to provide an estimate of how much disk and CPU resources would be consumed if journaling had been active when the monitored database activity took place.
The toolset consists of two CL commands that are created during the installation process. The Start Pseudo Journal (STRPSJRN) command identifies which database objects you would like to monitor. This activation step can be a long-running operation, so it's recommend that the STRPSJRN command be executed in a batch process. In the following example, you'll see that only a single DB2 object has been specified on the FILE parameter.
NBRSAMPLE(50) INTERVAL(20)
The FILE parameter also supports a generic (i.e., wildcard) file name or *ALL to allow you to monitor all the DB2 tables in a library. The DTAFILE parameter specifies where the command will keep all of the monitoring statistics. You can use the NBRSAMPLE and INTERVAL parameters to control how much overhead the STRPSJRN command adds to your system. The NBRSAMPLE parameter controls how many times the Pseudo Journal tool will wake up and collect activity statistics for the specified DB2 object(s). The associated INTERVAL parameter specifies in seconds how frequently the Pseudo Journal tool is activated. In this example, the tool will collect 50 activity samples with the samples occurring every 20 seconds.
Once all the samples have been collected, the Display Pseudo Journal Data (DSPPSJDTA) command is used to take all the raw data and generate reports that display the estimated disk and CPU resources that would be added if journaling were started for the specified database objects and the monitored changes. Here's an example of the command:
The DTAFILE parameter must match the same value used on the STRPSJRN command. The FILE parameter allows you to display the journal estimate reports for all the database objects (i.e., *ALL) monitored by the STRPSJRN command, or you can specify individual DB2 table or file names to focus your journal analysis to a smaller set of DB2 objects. The Report Type (RPTTYPE) parameter allows you to select one of three ways to view the journal estimate reports.
The Summary report (*SUMMARY) is probably the easiest report to start with. If you're displaying the journal estimates for multiple database objects, this report will show the journal overhead estimates for all of the DB2 objects. The List report (*LIST) returns the journal overhead estimate for each individual database object.
Here's a snapshot of the more interesting estimates returned by the Summary and List reports:
DISK WRITE SUMMARY==========
Disk Writes 4.014 K
Disk Writes W/Caching 3
JOURNAL STORAGE SUMMARY=======
Total Data 353.044 KB
Total Data (W/O Before Image) 348.873 KB (without Before Images)
JOURNAL DISK I/O THROUGHPUT SUMMARY========
Average Throughput 361 B /s
Maximum Throughput 4.936 KB/s
PERFORMANCE SUMMARY=======
CPU Overhead 48.168 ms
CPU Overhead w/caching 24.084 ms
.
Added Elapsed Time 1.204 ms
Added Elapsed Time w/caching 0.001 ms
One key thing to notice in these reports is that not only do you get raw estimates for the disk and CPU resources required by journaling, but you will see that the report also includes more advanced estimates that take into account optional journal settings—for example, how much reduction can occur in the journal disk storage requirements if before images are not journaled or how much disk and CPU performance be improved with Journal Caching (i5/OS licensed feature number 42) installed.
A Histogram report type is also supported, allowing you to see if there are any periods in time when the estimated journal activity would peak severely or if the journal overhead is constant. You should be aware that none of the reports produce a recommend system configuration. The customer is responsible for using these CPU and disk resource estimates to determine whether any system upgrades are needed in order to accommodate journaling on your server.
There's not enough room to go into all of the details of this new toolset, but there's plenty here to get you started. The Pseudo Journal tool can be used on any V5R3 or V5R4 server. IBM does plan to improve the toolset and documentation, so you should visit the Web site on a regular basis. It should be noted that this toolset is not officially supported by IBM, so the toolset is provided to you "as is" without any warranties of any kind.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online