It is August and hopefully by now the July CPU or PSU has been applied to your environments. Just like tuning the security patching is something we do to maintain a secure environment, but unlike issues this can be a scheduled process.
Knowing what to test, when to apply and how to apply should all be part of a security patching policy and process. The security and compliance group might be requiring these patches from you or it might be something as a responsible DBA that you are applying, but they are part of the secure configuration.
Even if a process has been developed, it might be a good time to review the process and take a look at some of the options available with Configuration Manager and PSU vs. CPU. IOUG is also interested information around security patching, as we are parterning with Oracle to conduct a survey around patching. To take the survey go to the IOUG Enterprise Best Practices SIGs website:
http://enterprisesig.oracle.ioug.org
Another way to review your patching process or gather the information needed to create on is to attend the webcast on August 11th. For registration:
https://www1.gotomeeting.com/register/141106952
Oracle will be talking about the differences in the CPU and PSU, how they test security patching, and share about how other companies are doing it. That is really the advantage of the user group isn't it, to be able to learn best practices from others that have to do the same tasks. This could be a great sanity check to confirm the process and information, or it might even have a step that you might not have thought of. Also if you have additional things you do to make the process easier, please share that idea with us to as there will be time for comments and questions.
Tuesday, July 27, 2010
Continuous Tuning
Having a stable database environment includes continuously making sure that things are running as they should. Load processes complete in the normal times, queries run in expected return times. Even as more and more data is added to the system, there is the expectation that things should run in the same times. Monitoring here is important to make sure queries and jobs are running in the times expected, and when slow downs occur you will be ahead of the game if you had been monitoring the times and noticed now additional minutes of run times.
So, what to do? Adding more data to the database is a normal occurrence, and just because things were tuned and indexes were being used previously, the increase in data could have changed things around. Good place to start is with statistics. Making sure that the statistics are current and the estimate percent provides the information for good query plans.
Next indexes, because a query that might have been just using the primary key might now benefit from a more focused index. Also, if possible, check and make sure the query still makes sense or if there is a more efficient way to write the query.
Not only statistics and indexes should be areas to look at for systems that are just continuing to grow, but memory settings, disk space and redo log sizing are all other potential areas.
If now the transactions are bigger and there are waits on log switches this would be something that can be adjusted quickly.
These are all good areas to check and monitor. One sure way I know that the database has been growing in size are the backups. Monitoring backup times and backup file size is a good way to compare, and if the size and timing of the backups have changed dramatically, it would be good to start checking on other areas for performance.
So, even if nothing is changing in the application and things appear to be stable, monitoring size and performance as things grow is part of keeping the database environment stable.
So, what to do? Adding more data to the database is a normal occurrence, and just because things were tuned and indexes were being used previously, the increase in data could have changed things around. Good place to start is with statistics. Making sure that the statistics are current and the estimate percent provides the information for good query plans.
Next indexes, because a query that might have been just using the primary key might now benefit from a more focused index. Also, if possible, check and make sure the query still makes sense or if there is a more efficient way to write the query.
Not only statistics and indexes should be areas to look at for systems that are just continuing to grow, but memory settings, disk space and redo log sizing are all other potential areas.
If now the transactions are bigger and there are waits on log switches this would be something that can be adjusted quickly.
These are all good areas to check and monitor. One sure way I know that the database has been growing in size are the backups. Monitoring backup times and backup file size is a good way to compare, and if the size and timing of the backups have changed dramatically, it would be good to start checking on other areas for performance.
So, even if nothing is changing in the application and things appear to be stable, monitoring size and performance as things grow is part of keeping the database environment stable.
Subscribe to:
Posts (Atom)