Test the Solution

If you have only one system, your process of sequential changes automatically ends up with the proper changes made to the system. If you have multiple systems or if you're dealing with a product that you have in multiple locations, you can then make the changes all at once to all of the other systems. Be aware, though, that systems that are supposed to be alike are not necessarily alike. Monitor the performance after the changes just to be sure that somebody's unique configuration does not interfere with the success of your changes. There are several questions to ask.

Does it Solve the Immediate Problem?

This should be fairly simple to determine. You've been focusing on this problem for a while, and you shouldn't have any problems deciding when it's fixed. Go to your bencmarks for performance problems and to your logs or other diagnostics for other problems.

Try not to want your solution to work so much that anything that it does looks like success to you. Try to be objective and look at it from the user's perspective.

Does it Create Other Problems?

This question is more difficult. If your fix causes problems in other areas, it may not be apparent immediately. It may be a month before the program that broke with this fix gets run again, and by then everyone may have forgotten that you did something that caused it to break.

Continually fixing one thing while breaking another is not usually conducive to advancing your career path. If anyone relates the fix to subsequent problems, you come out looking like an idiot. After you make any type of change, make sure that the system undergoes more strenuous monitoring than usual for the next few weeks, at least. Let your users and other administrators know that you've made changes, and alert them to possible symptoms or indications that may be caused by possible side effects of other interactions. If you do this and actually do see subsequent problems, you end up looking more like a guru than an idiot, since you've anticipated potential problems. Of course, if the subsequent problems entail completely destroying the database or bringing it down for days, you're back to being an idiot again.