IOUG blogs

The IOUG and Oracle have recently teamed together to survey IOUG members and non-members about the benefits of being a member of a user group.

The survey is open to everyone who is involved in the user community and I encourage everyone to vote before Thursday, July 3 (that’s this week!).

To vote you can press this link: http://www.oraclesurveys.com/se.ashx?s=251137454671BECB

and have Oracle hear about the values that a user group provides.

This is an important time in being part of a community and just as important to voice your opinion so that we can build a strong user community with a strong voice within Oracle.

So have your voice heard and vote today! And thanks for taking the time.

   When working on a data warehousing project that will be deployed on an Oracle platform, the discussions often turn to the Oracle database block size that should be used.

   We all know that in data warehousing environments one needs to move lots of data. This means that we are probably going to increase the size of the blocks in which Oracle will store data. The question then moves on to which one should we choose? Should we use 8KB, 16KB, 32KB or even 64KB. This is not a simple question to answer and if you ever did a search to find information on this decision; you find the information rare and often esoteric. The decision needs to be one that considers how information will be loaded and retrieved from your data warehouse.

   So when we decide we look at our data usage. We know that we will be loading millions of rows a data via a bulk loader like DataPump; we know this benefits from larger block sizes as the writes will pack more rows into each database block. We know that we are going to be doing updates during the DW process, so if are going to do any lookups then we need consider that these blocks will contain a larger number of rows, which means our reads will also retrieve more information than we really need. As for the reporting perspective; generally this will require reading larger volumes of data for analysis and aggregation. Again this benefits from larger block size by reducing the number of individual reads, which is good. Now we need to consider multi-block read counts. If we have increased the size of blocks and teh multi-block read count, means that we may move large amounts of data through our I/O channels that may cause bottlenecks, so this is another area that we need to manage and be concerned with.

Ultimately there is no right answer, other than it depends. It depends on the exact nature of your data and your data usage. This must be balanced with the server to optimize performance. The last thing we want to do is introduce new bottlenecks. Generally data warehouses will see block sizes that range from 8KB to 32KB, with multi-block read counts in the 8 to 32 range. Bottom line is test what works for you using a real world load to determine what works best for you.

The fact that we work close to people on a daily basis does not necessarily mean that we are communicating on the same levels. We need to consider communications internally and externally with a project team as one of the critical factors to a successful project.

We often work as part of a project team that needs to become the well oiled machine where all are participating actively in all aspects of the project; especially communications. Projects often set up communications plans that include a number of items. These plans will include regular meetings (daily and weekly), project dashboards, project wiki’s and other documentation and methods. These methods of communication work. A project that has clear communication plans and processes are projects that have a communication foundation for doing this well.

The key to any plan that you may enact really require cooperation rather that communication. The idea is that people need to understand the value of this type of information exchange. The team must be willing to share knowledge and information. The members of the team must be ready to share success and to know when to ask for advice. So it important to provide a facility where this information exchange can occur.

Communications are not simply about telling people what is going on and what is going to happen but it should also include a component of knowledge exchange. During any development project the team members must be willing to share information about the better way to do things. The ability to share best practices at a project level can be a critical factor in a project achieving its goals. We need to make sure we are not simply informed by that we are more knowledge about the project and the methods that we should use on each and every project.

Good communications during a project will help you and your project succeed. Just remember talk about things and make things better. The only real problem or issue on any project is one that is unspoken so make sure your project team is open and involved.

 

Building the right team is a subject that we have discussed before, but I wanted to talk about how to put the right team together and what skills are needed to build a data warehouse or business intelligence solutions.

So who is on the team?

• Project Manager
• Data Warehouse Architect
• Business Analysts
• ETL Lead Developer
• BI Lead Developer
• QA Analyst
• Various other developers and analysts.

So where do we start? The key to me in any successful data warehousing project is having someone who can be the Data Warehouse Architect. This is the person who will drive the solution and ensure that the most efficient solution is implemented. This person must have the ability to understand DW/BI technology and understands how to translate business needs into a solution. This person will directly impact the project’s success so choose carefully and choose experience.

DW and BI projects need standard project management controls, as many projects are complex and have many moving parts. This person should be knowledgeable in the DW and BI arena. Just another project to manage.

The ETL and BI Leads are also critical to the ultimate success of the project. These people will create and establish the approach that will be used to deploy the system. These people are generally the most experienced technology people on the team and can provide leadership to the rest of the development team. These people may also be development leads, but generally we try to focus these roles on ensuring that development is executed as needed.

Finally you need you QA, analysts and developers who will fill the remainder of the team.

Ultimately the team will need to work well and the leads are important people who must ensure that communication occurs between various people so that everyone understands their role in the overall project and can see how it contributes to success.

So build the right team with the right people who want to build solutions that provide organizations with competitive intelligence capabilities.