It is great being involved in the IOUG because it is a perfect place to be able to learn about new things. You can find out through webcasts, face to face seminars, white papers and conference how other users are using the technology and solving business issues and problems.
I enjoy venturing out and learning about other technology. Recently I started to take a closer look at ApEx which has helped in several ways. It is also fun for a DBA to dabble in development too. MySQL is another area.
Yesterday in Chicago, IOUG had a seminar on MySQL. It provided great information about some typical problem areas and how to resolve some performance issues. There were a couple of suggestions around logs and parameter settings which I was actually dealing with last week, but now have better solutions for.
The other thing that was mentioned and discussed was what some of the platforms would be used for. Oracle has it's place as an Enterprise database solution, MySQL provides some good coverage in the web space and has different engines for different usages. Also with the new releases there are more features being built in to expand its usages.
So, I am going to be learning more. October I'm attending OpenSQL Camp, http://opensqlcamp.org/Main_Page, and look forward to learning from others how the open source databases are being used and what is being developed in these areas.
Also Collaborate 2011 - IOUG Forum is going to have content on MySQL. Besides the features or options, such as replication, clustering with MySQL, there will be sessions to discuss how MySQL and Oracle work together in an environment. Now that is something more I understand. Being able to take different database platforms and use them in ways to meet business needs instead of throwing the same hammer at each need. It is definitely nice to have several tools to be able to work with to provide better solutions.
Wednesday, September 29, 2010
Wednesday, September 15, 2010
DBA Translations
I know I am not alone in having to deal with different database platforms. It seems to be more and more that way in companies. Reasons to have different databases for different projects, and we as DBAs don't really want to say no to different things to manage.
It would be nice to be able to focus in one database, but even with one database platform we probably have different purposes for those databases that we are dealing with. I believe that this is where some of the career growth is available for DBAs. One to understand different systems, two, to be able know why you would use one over another, and three, to be able to be a one stop place for database technologies.
So to add to the different database platforms I have started to learn MySQL this year, to go along with the list of Oracle, SQL Server, Sybase. Even when diving into the database platforms, I am looking for how to do a couple of things like backups, restores, performance tune and monitor for issues. These are the areas that need the translations of syntax and best practices.
Other SQL and how to get the data out of the database or load it, are also areas of translations. One statement or index might work great in one platform but switch over to something else, and you are having to rewrite or even plan another strategy.
I am getting ready to head to Oracle Open World where I can continue to learn about Oracle and now MySQL, but I am also giving a presentation on this topic.
With having to survive in these environments of multi-platforms, how does a DBA leverage their skill set and make those translations easier. I think that besides dealing with a lot of data that this is a challenge we face to learn and understand quickly and jump back and forth between environments.
Ok, so since I already put a shameless plug for my session at Oracle Open World in here, I might as well mention my book is out on the translations from SQL Server to Oracle database administration: "Oracle Database Administration for Microsoft SQL Server DBAs".
Besides supporting different environments there is moving, reading and updating data between the different environments. This could be part of regular processing or moving data to reporting systems for business intelligence, but gathering the data. no matter what the source, to be consumed by the people that need it is the goal.
Maybe this is topic for another time to discuss, linked servers, database links and ways to view and manage data. Besides understanding how to manage these environments it is another issue that DBAs face...so part two coming soon...
It would be nice to be able to focus in one database, but even with one database platform we probably have different purposes for those databases that we are dealing with. I believe that this is where some of the career growth is available for DBAs. One to understand different systems, two, to be able know why you would use one over another, and three, to be able to be a one stop place for database technologies.
So to add to the different database platforms I have started to learn MySQL this year, to go along with the list of Oracle, SQL Server, Sybase. Even when diving into the database platforms, I am looking for how to do a couple of things like backups, restores, performance tune and monitor for issues. These are the areas that need the translations of syntax and best practices.
Other SQL and how to get the data out of the database or load it, are also areas of translations. One statement or index might work great in one platform but switch over to something else, and you are having to rewrite or even plan another strategy.
I am getting ready to head to Oracle Open World where I can continue to learn about Oracle and now MySQL, but I am also giving a presentation on this topic.
With having to survive in these environments of multi-platforms, how does a DBA leverage their skill set and make those translations easier. I think that besides dealing with a lot of data that this is a challenge we face to learn and understand quickly and jump back and forth between environments.
Ok, so since I already put a shameless plug for my session at Oracle Open World in here, I might as well mention my book is out on the translations from SQL Server to Oracle database administration: "Oracle Database Administration for Microsoft SQL Server DBAs".
Besides supporting different environments there is moving, reading and updating data between the different environments. This could be part of regular processing or moving data to reporting systems for business intelligence, but gathering the data. no matter what the source, to be consumed by the people that need it is the goal.
Maybe this is topic for another time to discuss, linked servers, database links and ways to view and manage data. Besides understanding how to manage these environments it is another issue that DBAs face...so part two coming soon...
Tuesday, July 27, 2010
Security Patching
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.
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.
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.
Monday, February 1, 2010
Too late for Happy New Year
As most DBAs, stuff keeps us busy. Stuff has kept me busy. Some family and some other things relating to the IOUG and putting together great topics for upcoming webcasts and training for the user community and then of course there is the actual tasks of a day to day DBA.
It is actually Feburary already, and might be too late to wish everyone a happy new year filled with fun database opportunities and discussions.
Yes, we (I) get excited over debates about how to handle referential integrity, how much should different pieces of an application be handled by the database.
From the DBA perspective everything should be in the database, but developers will discuss that there are better tools available to handle things outside. This might not be always the case, but it might just be what both sides know or understand.
So, what is really valueable are discussions to understand and examples to demonstrate different areas. And this is not just one sided, hearing how they use the tools they have for creating processes is just as important for a DBA to understand and not dismiss as stuff outside of the database just happening. For some procesess on the database side, just saying it is really easy to load flat files into the database to perform ETL against them, is not enough if someone is not fimilar with how. Creating an example of an external table and some stored procedure for them to look at is better. But even better find out about a need that they have and teach them how to use these tools, such as external tables to see how it works for them in this situtation. They will then have a new tool in their belt to use, and be able to determine if it was valuable for them because it could have solved the problem faster or easier for them to learn. Being willing to understand both sides of how to solve a problem and being willing to work through solutions using different methods will present opportunities to share some of the database features and available options. Of course be prepared to also learn something as well, if there are some cool tools that they have to handle other pieces.
I enjoy these discussions and coming up with ways to solve business needs by using database technologies, and I hope for more open discussions and healthy debates to come up with better solutions.
It is actually Feburary already, and might be too late to wish everyone a happy new year filled with fun database opportunities and discussions.
Yes, we (I) get excited over debates about how to handle referential integrity, how much should different pieces of an application be handled by the database.
From the DBA perspective everything should be in the database, but developers will discuss that there are better tools available to handle things outside. This might not be always the case, but it might just be what both sides know or understand.
So, what is really valueable are discussions to understand and examples to demonstrate different areas. And this is not just one sided, hearing how they use the tools they have for creating processes is just as important for a DBA to understand and not dismiss as stuff outside of the database just happening. For some procesess on the database side, just saying it is really easy to load flat files into the database to perform ETL against them, is not enough if someone is not fimilar with how. Creating an example of an external table and some stored procedure for them to look at is better. But even better find out about a need that they have and teach them how to use these tools, such as external tables to see how it works for them in this situtation. They will then have a new tool in their belt to use, and be able to determine if it was valuable for them because it could have solved the problem faster or easier for them to learn. Being willing to understand both sides of how to solve a problem and being willing to work through solutions using different methods will present opportunities to share some of the database features and available options. Of course be prepared to also learn something as well, if there are some cool tools that they have to handle other pieces.
I enjoy these discussions and coming up with ways to solve business needs by using database technologies, and I hope for more open discussions and healthy debates to come up with better solutions.
Subscribe to:
Posts (Atom)