Say it real fast and it sounds like Twiki of Buck Rogers. (At least that was part of the discussion with some other Oracle ACE Directors.) The other part of the discussion was that this can provide a great way to consolidate, patch/upgrade and maintain Oracle databases.
So what do these new acronyms mean? CDB - Container database. The container database is the global area for the database and contains the main system information. PDB - Pluggable databases. The pluggable database is the user/application information and has the user tables and system information about all of objects in the pluggable database. This is a key new feature of the Oracle 12c database.
Just start to think about what this can mean. It means I can have a few container databases (CDB) and multiple pluggable databases (PDB) in each container. I can backup and recover a PDB to a point in time, I can clone a PDB in seconds and I can plug a database into a patched CDB and have that PDB now on the patched version as well. The PDB is isolated to other PDBs and now there are security options for access to a CDB and different logins for PDBs to keep access separate. The current databases, previous versions are now non-CDBs. There are also non-CDBs available in 12c, that behave like the current database instances with schemas and shared system information. They are easy to manage in the database tools, like database creation database, Oracle Enterprise Manager and SQL Developer.
The rest of the week at OOW should provide more information about CDBs and PDBs. This is a nice new feature of Oracle 12c and provides an easy way to manage different applications in one CDB. Faster too! Another bonus.
Monday, October 1, 2012
Oracle Technology
Why is technology fun? It is always changing and providing new solutions and new innovations. If you want
have a simple career then technology is not for you. Especially DBAs we have new things happening all of the time. More data, big data, faster hardware!
Yes, OOW does speak loud and proud about the Oracle technology and things that they are doing well and how they have the best of breed in the technology stack. It does also give motivation to see how to look at things differently, provide value to the businesses.
As a DBA, some things get simpler, while there are other opportunities in our jobs to keep us challenged. Cloud offerings, Engineered Systems, better performance with software and hardware are a few things that make things simpler. DBAs have the opportunity to look at managing these engineered systems, working with cloud offerings and database as service, and even developing more in the role of a Database Machine Administrator (DMA).
There are still challenges of data, what data business needs, integration of data, securing data for the business. Is this an emerging role as well for the DBA? Do we need Big Data DBAs? What is coming out that is a new feature that are benefits and should be implemented. Even if things haven't worked in the past or seen as something important, is it now?
That might be one interesting thought here, that even with previous years at OOW not seeing cloud as important, but willing to come back and see it with a new set of eyes and how there are benefits there now, are ways we should be looking at our database environments. Take a new look, take advantage of new technology, maybe look at a direction that was rejected in the past that might be worth it now. Same with the role of the DBA, not just creating database, adding users but new tools and new opportunities.
have a simple career then technology is not for you. Especially DBAs we have new things happening all of the time. More data, big data, faster hardware!
Yes, OOW does speak loud and proud about the Oracle technology and things that they are doing well and how they have the best of breed in the technology stack. It does also give motivation to see how to look at things differently, provide value to the businesses.
As a DBA, some things get simpler, while there are other opportunities in our jobs to keep us challenged. Cloud offerings, Engineered Systems, better performance with software and hardware are a few things that make things simpler. DBAs have the opportunity to look at managing these engineered systems, working with cloud offerings and database as service, and even developing more in the role of a Database Machine Administrator (DMA).
There are still challenges of data, what data business needs, integration of data, securing data for the business. Is this an emerging role as well for the DBA? Do we need Big Data DBAs? What is coming out that is a new feature that are benefits and should be implemented. Even if things haven't worked in the past or seen as something important, is it now?
That might be one interesting thought here, that even with previous years at OOW not seeing cloud as important, but willing to come back and see it with a new set of eyes and how there are benefits there now, are ways we should be looking at our database environments. Take a new look, take advantage of new technology, maybe look at a direction that was rejected in the past that might be worth it now. Same with the role of the DBA, not just creating database, adding users but new tools and new opportunities.
OOW 2012 - Keynotes
Oracle Cloud and Engineered Systems mentioned already last night, and today is going to be a good day for the database. More details on the latest version of the database should be provided.
Even though the keynotes are a high level about Oracle products and the stack, they give a a good picture of what is currently important to the Oracle executives and direction that the Oracle products are heading. Get the big picture first and then follow up with sessions to dive into more details.
The other great opportunity is to network with the user community and see who is looking forward to implementing new features and what products have been game changers in their company.
Even though the keynotes are a high level about Oracle products and the stack, they give a a good picture of what is currently important to the Oracle executives and direction that the Oracle products are heading. Get the big picture first and then follow up with sessions to dive into more details.
The other great opportunity is to network with the user community and see who is looking forward to implementing new features and what products have been game changers in their company.
Wednesday, January 25, 2012
Security DBA Responsiblity
"It would be easier to implement a patch policy if it came from management and we could get downtime", "I don't know what data to encrypt so the application owners need to tell me", "Isn't it the security team's responsibility to make sure that access changes when the jobs change". These are probably things we have heard DBAs says and maybe have even said them ourselves. Security is something that a DBA is responsible for implementing but where does the responsibility end?
I was reminded the other day about this topic and started to think about this. If there was an outage because something happened for an upgrade, and the DBA was not able to restore the database, is that the fault of the upgrade or not being able to restore? Again we can probably argue both, and at the same time I am thinking if I wasn't doing everything possible to assure that had good backups and could restore from them, I would fault myself.
Yes, it is definitely easier if it isn't just coming from the DBA team that security patches need to be applied, and if there were top down mandates to govern security practices, but what can be done by the DBA?
One, patches should be applied to the system and the DBA can have a solid implementation plan in place to make this easier. Probably if patching was successful on a regular basis the outage or maintenance window would be easier to get. A good test plan with reviewing of pre-checks and post-scripts to make sure everything gets covered in a step by step way. This process is something the DBA can own and promote. A well documented plan with details about testing and success rate.
Two, encryption at the tablespace level. This is transparent to the application, and if the DBA knows that the database can have sensitive information, then it is definitely worth raising the risk of what happens if this data at rest is accessed. Encrypting the tablespace means that you don't have to know exactly what fields are sensitive either. It would be great to have these conversations to control access and mask this data in test environments, but at least reducing the risk of data at rest and outside of the application is worth it. This also is a feature that is fun to implement as a DBA, because it is on the back end and is how you create the tablespace.
Three, protect yourself from seeing data you don't really want to see in the first place. Being able to prove out that even with sysdba permissions you can't see the data in a database vault realm protects you knowing what you really don't want to know. Using database vault does protect the data from the administrators, but still allows for the job to get done. Database vault is an option that can be configured after creating the database using dbca (database configuration assistant). The realms would be managed by someone outside of the DBAs or SYSDBA to make sure that these permissions cannot be granted back to the SYSDBA.
Four, check out the database firewall. We should be evaluating and looking at new security features. The firewall can help in the fight against SQL injection, and examining new features and doing the research would be useful to understanding if it is something that would be of value and reduce some risk in your environment.
Five, educate business and users of the environment. This would also tie in the research about features. After the initial understanding of what can be secured, monitored and implemented, then it is time to talk. Discuss what it takes to implement and the risk, which is a great way to look at some of the value you can get out of securing the environment.
These are good steps to be taking as a DBA to provide a secured database environment.
It is not necessarily going to be the easier road to take, but there are some things we can do. And there is persistence on our side because I would definitely like to error on the side of trying to implement the needed security and communicating the risks, then being caught when it isn't implemented and not having even tried.
I was reminded the other day about this topic and started to think about this. If there was an outage because something happened for an upgrade, and the DBA was not able to restore the database, is that the fault of the upgrade or not being able to restore? Again we can probably argue both, and at the same time I am thinking if I wasn't doing everything possible to assure that had good backups and could restore from them, I would fault myself.
Yes, it is definitely easier if it isn't just coming from the DBA team that security patches need to be applied, and if there were top down mandates to govern security practices, but what can be done by the DBA?
One, patches should be applied to the system and the DBA can have a solid implementation plan in place to make this easier. Probably if patching was successful on a regular basis the outage or maintenance window would be easier to get. A good test plan with reviewing of pre-checks and post-scripts to make sure everything gets covered in a step by step way. This process is something the DBA can own and promote. A well documented plan with details about testing and success rate.
Two, encryption at the tablespace level. This is transparent to the application, and if the DBA knows that the database can have sensitive information, then it is definitely worth raising the risk of what happens if this data at rest is accessed. Encrypting the tablespace means that you don't have to know exactly what fields are sensitive either. It would be great to have these conversations to control access and mask this data in test environments, but at least reducing the risk of data at rest and outside of the application is worth it. This also is a feature that is fun to implement as a DBA, because it is on the back end and is how you create the tablespace.
Three, protect yourself from seeing data you don't really want to see in the first place. Being able to prove out that even with sysdba permissions you can't see the data in a database vault realm protects you knowing what you really don't want to know. Using database vault does protect the data from the administrators, but still allows for the job to get done. Database vault is an option that can be configured after creating the database using dbca (database configuration assistant). The realms would be managed by someone outside of the DBAs or SYSDBA to make sure that these permissions cannot be granted back to the SYSDBA.
Four, check out the database firewall. We should be evaluating and looking at new security features. The firewall can help in the fight against SQL injection, and examining new features and doing the research would be useful to understanding if it is something that would be of value and reduce some risk in your environment.
Five, educate business and users of the environment. This would also tie in the research about features. After the initial understanding of what can be secured, monitored and implemented, then it is time to talk. Discuss what it takes to implement and the risk, which is a great way to look at some of the value you can get out of securing the environment.
These are good steps to be taking as a DBA to provide a secured database environment.
It is not necessarily going to be the easier road to take, but there are some things we can do. And there is persistence on our side because I would definitely like to error on the side of trying to implement the needed security and communicating the risks, then being caught when it isn't implemented and not having even tried.
Friday, February 4, 2011
Get the information fast
I was reminded today, it is good to be a DBA. A DBA can mean so many things and have many different roles. It definitely keeps my life interesting.
Data can be very helpful to the business and provide important information to make decisions, execute transactions and keep things moving. The problem for the DBA is to keep things moving. Existing system can be monitored to check if queries are executing efficiently or if there is anything bogging the system down. One day things might be running great and the next day it only one query is barely getting through. What happened? Things might have changed, a batch job could have run long. Are backups still running? Statistics? If applications are running slow, the question comes back what is wrong with the database.
At this point if you are a pro-active DBA you have a question back! is this a normal process or is this something new? It seems like we are pulling more data, new data loaded? Thank goodness for tools and those monitoring scripts that are in place. How can I tell this point can you quantifiy the problem.? Only if you have some benchmarks, you can then tell if there is more data, how much slower things might be running. Simple benchmarks on basic application queries, backup times, how long to gather statics can help with how slow or fast things are running. Space benchmarks, object counts and object changes also provide good benchmarks for the system. If gathering this information, the benchmarks are there for changes. Because I have to ask if you make improvements and can't tell anyone how much you improved, what fun is that!
Another nice things about proactively monitoring the performance, when there are issues, you already have quick information and can start looking into other things for the problem. Monitoring the performance is something you are continuously doing, because things do change.
Systems van be designed and configured for performance. The initial build and implementation should take performance into consideration.
I am looking forward to an upcoming IOUG Training Day that addresses this topic of real world performance and archectiting database systems to get the information fast. Real World Performance
Data can be very helpful to the business and provide important information to make decisions, execute transactions and keep things moving. The problem for the DBA is to keep things moving. Existing system can be monitored to check if queries are executing efficiently or if there is anything bogging the system down. One day things might be running great and the next day it only one query is barely getting through. What happened? Things might have changed, a batch job could have run long. Are backups still running? Statistics? If applications are running slow, the question comes back what is wrong with the database.
At this point if you are a pro-active DBA you have a question back! is this a normal process or is this something new? It seems like we are pulling more data, new data loaded? Thank goodness for tools and those monitoring scripts that are in place. How can I tell this point can you quantifiy the problem.? Only if you have some benchmarks, you can then tell if there is more data, how much slower things might be running. Simple benchmarks on basic application queries, backup times, how long to gather statics can help with how slow or fast things are running. Space benchmarks, object counts and object changes also provide good benchmarks for the system. If gathering this information, the benchmarks are there for changes. Because I have to ask if you make improvements and can't tell anyone how much you improved, what fun is that!
Another nice things about proactively monitoring the performance, when there are issues, you already have quick information and can start looking into other things for the problem. Monitoring the performance is something you are continuously doing, because things do change.
Systems van be designed and configured for performance. The initial build and implementation should take performance into consideration.
I am looking forward to an upcoming IOUG Training Day that addresses this topic of real world performance and archectiting database systems to get the information fast. Real World Performance
Wednesday, September 29, 2010
MySQL and IOUG
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.
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 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...
Subscribe to:
Posts (Atom)
