Database Post Mortem

Posted on 27/04/2012 by Irad Deutsch

There is something I have to share with you. Not so long ago I attended a meeting at one of our customers. Every now and then I leave the warm office and meet our customers eye to eye to make sure our product is aligned with our end users expectations.

One of these customers asked me if I could take a look at their environment and find out what happened to their database 5 days ago. They had experienced a database crash and were wondering why.
Lucky them – they had MoreVRP installed, but not the entire package. I suggested to install some add-ons including the Playback module in order to look back in time at the last seconds before the database crashed.

In less than 10 minutes, we started watching the events as if we were viewing a movie in slow motion. Second by second. Our customer was watching too – he didn’t need my explanation. He immediately understood what was going on during the last seconds before the breakdown. We witnessed a chain reaction where one query caused a problem to another one and this caused a snowball effect. Using the variance module were able to prove it was the first time these queries were executed in this environment, so there was no doubt they had a lot to do with the crash.

Top SQL lists are ok… but when you need to dig into a few seconds or a minute historically, they just aren’t enough. You need something by far more granular, that can show how the problem occurred and evolved second by second… and this is where the MoreVRP playback module shines.

I hate doing post mortem analysis because I believe most problems can be avoided before they even start. But having the ability to do this with scalpel precision at your disposal is definitely a big plus.

Irad

 

Posted in Conceptual, Customers Stories, Technical | Tagged , , | Leave a comment

Efficient solutions for crisis management – VRP

Posted on 04/10/2011 by Irad Deutsch

Written by : Guy Erez, International Pre-sale, MoreVRP

If you administer a system that includes a database, you will relate to the following. It doesn’t matter how your servers are configured, what applications you run or how up to date you are, todays bleeding edge is tomorrow’s history. The race against that single peak that will destroy your database stellar performance is always behind the corner. There is nothing we can do. Or is there?

Our traditional ways to fight that kink include extremely high ongoing costs; upgrades upon upgrades create the endless loop of accumulating operating costs. We never have the time to stop and ask ourselves why. Is that single point of panic the real indication of our database systems capabilities? Does that sudden surge in usage, whether from big reports being generated or the few extra users momentarily accessing our databases really mean our systems are obsolete? So we spend our time during crisis situations putting out fires and trying to unclog that bottleneck! Of course suddenly we become the point of focus. How come we couldn’t avert this situation, or at least predict it or be ready for it? Our complete resources (human and digital) are converging to that single point in time, suddenly our regular 9-5 with all the tasks at hand have no meaning or importance. In order for the organization to go on this one problem has to be solved and dealt with now!

Once the crisis has past we get the call! Full damage report ASAP, full recommendation strategy meetings etc.. Suddenly production, finance and upper management become experts and each one of them tells you how to do your job! Your instinct says get bigger and better. If you have a sized database you know very well it’s not a “radio shack” plug and play purchase and that’s it. Time is required to conduct tests, tweak the software were it needs to be tweaked and more. The cycle will take at least 3 month and even then things won’t be 100%. Part of your human resources will be busy with the update/upgrade process instead of the accumulated tasks at hand. In other words this is an accounting nightmare, no matter how you look at it.

What more, the time that your current system is running idle or almost idle will stay the same. Your unused resources are still being wasted. And you know very well that by the time you get to that next bottleneck you will be doing the same dance.

The big question is what are the options?

Ultimately the answer lies in a simple statement, crisis situations can be avoided if have CONTROL over your processes and resources. Let’s face it, most crisis situation are created by peak demands which are usually not part of your day to day cycle. The surge is due to a few operations, which could be end of month reports, peak of customer support demands and more. These anomalies create a surge and/or bottleneck that overload your system and bring the entire operation to a screeching halt! If you could restrict the resources available to these few anomalies the rest of the workload would continue consistently. A traditional solution is dedicating hardware and separating environments. The issue there is that during of peak times you have systems sitting idle which translate to money down the toilet.

The most efficient way to manage your available resources is virtual resource partitioning. This process in effect allows you to control which process uses what amount of resources that are available through your system. Through careful analysis of trends within your operation you have the capability to predict how your system will be affected in certain situations and avert the crisis by setting rules that will manage your resources accordingly. This process also extends the time between upgrades due to the efficient allocation of available resources. Moreover such system allows you to create general rules of stability that can keep your systems in check and below the red line at any time, no matter what the consequences, even in a state of crisis your users will never feel that the entire operation is at a standstill.

Posted in Uncategorized | Leave a comment

Database Consolidation – top 5 things you must consider

Posted on 13/09/2011 by Irad Deutsch

One of the ways to cut IT costs is by consolidation. Taking several applications and consolidating them into a single infrastructure. It can be a standalone server or a grid of servers, but generally speaking – a single unified infrastructure.

Databases are one of the entities you should consider consolidating in order to cut IT costs. Not only does it save hardware and software cost, it also saves time and money in terms of support and management.

There are many vendors out there that offer consolidation environments. Some are just offering their existing database technology wrapped with high availability and DR features that make them more robust, while  others, like Oracle for instance, offer a solution such as Exadata as a Database appliance that suits both OLTP and Data Warehouse (DW) systems and targets the consolidation market.

But just before you dive into a consolidation project – you must take these top 5 elements into consideration, they have to be on your check list :

1. Unified management

It doesn’t make sense to consolidate all your databases into a single infrastructure, if you can’t manage all your databases as if they were one, while keeping the ability to drill down to each and every one of them separately if needed. Unified management is crucial if you don’t want to spend too much time on support tickets and management tasks.

2. Unified performance View

When it comes down to performance analysis, seeing just one database at a time doesn’t show the whole picture. Having the ability to see all performance metrics as if it were one database, while allowing you to drill down quickly and easily – is crucial. It is also essential that you have a extensive historical performance repository that will allow you to investigate performance problems down to the individual SQL execution. Solving performance problems in a consolidated environment is by far more important since it doesn’t only affect the affected database, it also radiates to all other databases.

3. Quality of Service

What happens when one of your 100 consolidated databases, becomes busy ? It eats up all available resources causing resource starvation for all other 99 databases, which lead to Quality of Service and SLA problems. You can’t enjoy the fruits of consolidation while having your end users complaining all day long about un-stable response time.

4. High Availability

When you consolidate many databases into a single server/cluster/grid, there is always a chance that when this server becomes extremely busy and unstable, it will affect all your databases and applications. In some clusters (for instance Oracle RAC, Exadata or Greenplum, Netezza…), when one node becomes 100% utilized, it radiates to the other servers thereby slowing them down as well. This is a major risk in any consolidated environment.

5. Chargeback

You are not far from the day when all IT divisions out there, will start charging their internal customers based on actual resources usage. It doesn’t make sense for that IT division to keep on scaling out/up their systems because developers produce poorly written code. Many organizations consolidate many databases while seeking solutions in order to track resource consumptions at the DB level (or tenant level), limiting resource consumption based on the real need of that tenant, and creating billing reports based on the actual usage of CPU , IO and disk space on a monthly/quarterly basis. Even if you are still not going to charge your customers, you certainly want to produce this kind of report and share it with your superiors  and customers.

MoreVRP is the only solution that addresses the database consolidation environment  the way  it should be addressed – covering all these 5 major aspects.

  • Unified management and performance analysis – MoreVRP gives the end user a unified management and performance analysis dashboard that can take the end user from a unified view down to a SQL statement in one of the databases. You have the ability to see which is your hottest database in a unified list, find performance differences between different nodes in your cluster/grid, identify un-balanced layout of databases resource utilization and even see a “top queries” list of all databases together. These capabilities, and many others allow DBAs to easily manage and analyze their consolidated databases while dramatically shortening troubleshooting cycles .
  • Quality of Services – MoreVRP is the only solution in the market that allows you to partition your resources (CPU and IO) in real-time in an accurate way and in real-time to make sure one database will not consume more than its allowed quota while boosting other more important databases.
  • High Availability – MoreVRP protects your system using the MoreVRP rules of stability, not allowing a node within your grid/cluster to reach its boiling point (100% CPU or IO) while protecting your systems stability and availability.
  • Chargeback – Using the Chargeback module, MoreVRP allows you to define your tenants based on any parameter you wish, track their resource consumption, force them not to consume more than they are allowed or really need, and even create the billing report.

MoreVRP now supports Oracle DB, Oracle Exadata, SQL Server, DB2, PostgreSQL and EMC Greenplum. If you consider using any of these database platforms for your consolidated environment, check out what MoreVRP can do for you.

And by the way – there is also a BONUS. MoreVRP will help you out during the transition process. Our Variance module can compare the “before consolidation” and “after consolidation” performance metrics, helping you solve performance obstacles and even show you how much time and money you saved during the process.

To read more about this – check out this post about database migrations.

Posted in Conceptual, Technical | Tagged , , , , , | Leave a comment

Database migrations & upgrades. Does it really have to be that complicated ?

Posted on 13/08/2011 by Irad Deutsch

Did you ever upgrade your database to a newer release and got hit performance problems ?

Did you ever upgrade your storage or server and didn’t see the performance boost you were looking for ?

I know I have. Many times.

One of the challenging tasks for every DBA is migration and upgrade projects that involve the database. It could be any of the following :

  • Application upgrade – where some if not all of the changes are applied to the scheme, structure and code within the database.
  • Database upgrade (for example Oracle 10G to 11G, or SQL 2005 to 2008)
  • OS migration – when you think of moving your database from HPUX to Linux for example
  •  HW upgrade – when you add more horsepower to an existing server, replacing your storage array or just move your database to a new box.

The main incentive in such projects is to make our system better. Sometimes it’s all about availability, sometimes it’s about performance. But there is one risk that puts any migration/upgrade project in Danger… Performance !

I have seen DBAs migrating and upgrading their databases in QA/TEST where it all went well in terms of performance, but when they go live – they start to hit major performance problems.

When you get a new piece of hardware, you test it in your lab before going live. However  - can you really be certain that once you move your production database to that box – you will not experience any performance problems ?

Well – This is what we are here for. In my previous post – I preached about how our Variance module can answer a simple question : “Why my performance today is not as good as it used to be yesterday”. But this time I want to talk to you about how it can become a fundamental building block in any upgrade/migration project you plan.

MoreVRP Variance is all about comparing. Identifying performance differences within the same environment, or between different environments.

Here is a story :

Customer X, spent approximately 1 million dollar on a new storage array. During the testing period – it looked like this new monster is going to solve all his IO bottlenecks.

However, when he moved to production, not only didn’t he see any performance improvements, he experienced a dramatic slowdown.

Within 2 days – the DBA ran out of excuses, and he remained speechless whenever he was asked by his Boss “Why?”. The deal was about to be canceled and X was starting to plan his way back to the old clumsy storage he had… Not to mention the bad reputation for that particular storage vendor.

“Lets do some comparisons using the MoreVRP Variance module” someone suggested. It took no more than a few minutes to identify that many execution plans had been altered in production… Why ? Well – in Oracle you have this thing called “System statistics”. Oracle can take into consideration not only the query you wanted to run, but also the overall system performance. If it “feels” that more IO resources are available, it can change the execution plan from a CPU bound plan to an IO bound plan thinking that it utilizes the database server in a more efficient manner. For some reason – the execution plans oracle had chosen weren’t really the fastest one. Disabling the system statistics feature just solved the problem.

See ? if you only find out what have changed then you are 80% on your way toward solving the problem. That’s what Variance is all about.

There are so many other use cases :

  • Migrating from Oracle 10G to Oracle 11G ? identify the plans that have changed (for worse) and fix them before going live
  • Benchmarking 2 database servers (Like Sun/Oracle Vs. HPUX or maybe DELL), run some scenarios on both boxes and let the MoreVRP Variance module tell you which one is faster and by how much.
  • Benchmarking 2 database appliances? Same thing. Let MoreVRP Variance be the judge.

Oh – and one last thing. Sometimes (just sometimes :) ) migrations and upgrades tend to go smooth. In this case you want to let everybody know how much better the performance is after the upgrade/migration. Let MoreVRP do the math for you and provide you with reports and graphs that you can then share with your boss and colleges, that shows how much better the performance became thanks to you and the project you have managed.

I wish you all the best of luck in your next upgrade/migration project. But don’t count just on luck. Count on MoreVRP.

Cheers.

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Why my database performance isn’t as good today as it used to be yesterday ?

Posted on 08/08/2011 by Irad Deutsch

MoreVRP Variance module : Why my database performance isn’t as good today as it used to be yesterday ?

No matter if you are a DBA, R&D Manager or QA manager, one of the most frustrating tasks is database performance troubleshooting.

You know the feeling. One day you get this email/SMS/phone call while your boss is on the other line screaming : “Do Something. The database is barely moving…”

Then you start digging in into all the metrics trying to isolate the cause of the performance problem.

The conventional way in database performance troubleshooting relies on what I call  “the top 10 hit list methodology” where you try to find your performance problems by looking into the top-10 IO consumers, top 10-CPU consumers etc. Most of the database monitoring tools (including those that the vendors themselves offer) are following this very conservative methodology.

We at MoreVRP have a different and very unique approach toward performance troubleshooting and it relies on the simple fact that if today the database performance is not as good as it used to be yesterday – something must have changed between these two periods of time. If we find the change, we can isolate it and we are 80% on our way towards solving the problem. That’s why we invented the “Variance” Module in MoreVRP.

So how does the Variance module find what has changed ? It compares. Maybe one query out of 100,000 is suddenly doing more IO  than usual ? Maybe there are a bunch of queries that weren’t there before (maybe the application team installed a new patch and forgot to notify us about it J), maybe an execution plan has been altered last night… These and many more, are just a few samples of changes that can trigger a performance problem. Finding this needle in the haystack (like an altered execution plan) is the longest and most frustrating phase in conventional performance troubleshooting, but with MoreVRP – it’s a no brainer.

Comparisons can be made between different timeframes within the same database, or even between databases (Like QA vs. Production). You can even compare different databases versions (Like Oracle 11G in QA vs. your Oracle 10G in production).

So who can benefit from this ?

If you are a DBA, then identifying the differences and isolating them in seconds, is crucial for performance troubleshooting – especially in production.

If you are a QA/R&D manager, you can use MoreVRP during your stress tests while isolating performance differences between the previous application version and the new application version that you are about to approve.

Considering to migrate between SQL 2005 to SQL2008 for example (same goes for Oracle, DB2 and Postgres of course) ? Compare the QA (2008) vs Production (2005), isolate those queries that behave differently, fix them and go live with no additional disruptions.

Variance : A new approach toward performance troubleshooting at your fingertips.

I think the best way to conclude this post is by quoting one of our customers : “Cool! for weeks I couldn’t understand why my database became so slow… Why didn’t you tell me about Variance before ?!?”

Posted in Conceptual, Technical | Tagged , , , , , | Leave a comment

Taking PostgreSQL performance management & tuning to a whole new level. Announcing MoreVRP for PostgreSQL !

Posted on 01/08/2011 by Irad Deutsch

I’m Excited. It has been a while since I have updated our Blog and that was due to some good reasons. One of them is that we have just release the MoreVRP for PostgreSQL.

I don’t know if you are a fan of open source databases, but reality shows that they are rapidly penetrating the database market.

I have seen companies using PostgreSQL as a standalone DB as an alternative for Oracle, SQL, MySQL and others. But we have also noticed how the MPP databases that are based on PostgreSQL databases underneath, also expand in a way that caught the big vendors attentions and of course enterprise customers.

As someone who’s been working with PostgreSQL for 6 years now – Let me tell you this : PostgreSQL is a very good database. Great performance, flexibility and stability. However – as a DBA I have identified a big gap between what the DBA community is looking for, and what PostgreSQL can offer. And it’s all about performance management and tuning.

This is why I proudly announce that MoreVRP now supports PostgreSQL (AKA MoreVRP for PostgreSQL).  So what do we really offer. Here are the highlights :

  • Instantaneous dashboard – real time dashboard that gives you an accurate reflection what what’s going on in your PostgerSQL database. You can see all active transaction in real-time and for each and every one of them – you can see the SQL statements, IO per sec, CPU %, Tags etc…
  • Rich data repository – MoreVRP collects all this data and stores it in a repository. You can than dig into the repository using the various graphs, pie charts and reports and pin point performance problems very easily.
  • Variance Module – for the first time ever, you can really answer the following question : “Why is my performance today, not as good as it used to be yesterday”. The Variance module allows you to discover performance differences between different time-frames (like today vs. yesterday) or between different environment (QA vs. Production) and identify the queries that have changed their behaviour (in terms of runtime IO etc..). So now you can find that the needle in the haystack you were looking for, in no time.
  • Virtual Resource Partitions (VRP) – Unlike most tools that just gives you red lights and alerts (we do that as well), the VRP engine can boost or slow down transactions in real-time by controlling the exact amount of CPU and IO taken by each and every one of them in your PostgreSQL database. Using VRP you can maintain stable Quality of Service (QoS), Maximize your HW utilization, and prevent slowdowns and even hangs or crashes.

The beautiful thing with MoreVRP for PostgreSQL, is that you don’t really need to be a PostgreSQL DBA or an expert in PostgreSQL performance tuning. If you know Oracle, SQL Server or DB2, you’ll feel at home while working with MoreVRP for PostgreSQL. The same interface which is very intuitive. You can become a tuning expert in PostgreSQL in no time.

Take a look at this demo. It shows how MoreVRP for Oracle works. But there is no difference between this and MoreVRP for PostgreSQL. You wouldn’t even feel the difference.

So PostgreSQL Performance management is now easier than ever.  MoreVRP for PostgreSQL takes PostgreSQL performance management to a whole new level.

Now you see why I am so excited ? :)

 

Posted in Announcements | Tagged , , , | Leave a comment

SSDs – are they really a solution for database performance issues?

Posted on 11/02/2011 by Irad Deutsch

Most of the databases with which I am familiar – still reside on rotating plates (A.K.A disks). Disks, physical disks, hard drives or whatever else you might call them – have been out there for many years, and they are one of the few products that haven’t really developed in a technological sense. Moore’s Law never really applied to disks. Only CPU power. Too bad… because when it comes to the amount of calculation a CPU can execute in a single second – we are making a great leap every 18 months, but when it comes to the amount of IO/sec we can process even when using a high-quality storage device – the mechanics that work underneath are still stuck somewhere in the late 80s or early 90s.

Recently, there is another new buzz catching everyone’s attention. This one is around SSD drives. Solid State Drives. SSDs are really good when what you want to do is to read a lot of data. They are especially good (in comparison to physical rotating disks) when you want to read a lot of data in small chunks – what is also called “Random IO”. I’ve had an opportunity to work with databases that reside on SSD drives or what are also called Flash devices. I’ve worked with databases stored on Flash drives, Flash cache, Oracle Exadata, and many other solutions. They all have one property in common: when the disk operates faster, the CPU tends to work harder to process the huge stream of data.

Up until now, physical disks have been the main bottleneck to performance improvement in most of the systems with which I have worked. But when you substitute the IO sub-system with an alternative that is capable of executing so-and-so many IO operations per second, instead of the disk being the bottleneck, instead this role goes to the CPU. I’ve seen this in real life.

Here is an example: I was working on a system with 4 Quad CPUs and SAN storage that was capable of processing 10,000 IO/sec tops. • When my disk capacity was 100% utilized, my average CPU utilization was ~40% on average, and it peaked at 70%. • When I replaced the storage system with an SSD that was capable of processing 100,000 IO/sec (ie 10 times faster than my old storage), I noticed that my CPU consumption was still ~40% on average, but it peaked at 100%! • Another thing that I noticed was that even though the SSD capacity is 100,000 IO/sec, it never went beyond a speed of 20,000 IO/sec (meaning that it was only 20% utilized). Why was that? Because now I don’t have enough CPU power to process this fast data stream… Now we all know what happens when a machine reaches 100% CPU utilization… it crashes, times out, hangs… And if someone runs a report on this machine, if before it would have jammed only the storage device, now it jams the machine’s CPU…

Now tell me something – if you have to choose from between these two options, which one would you prefer?

• working with a jammed, over-utilized storage device?

• Working with a jammed, over-utilized CPU?

I would choose the second option. Because even when my hard drive on my laptop is working hard, most of the applications that reside in my memory and consume only CPU are still working fine. But when my CPU is 100% utilized – the laptop is completely stuck. No processing ability, not to process IO, nor to carry out CPU calculations.

People told me “SSD is going to solve our performance problems”. Well… – no. It sure will speed up some of the things that you are doing. But it is not going to solve the other problem from which you probably suffer – that of QoS and SLA. As long as there are computers, performance bottlenecks will remain. If you make one component work faster without changing anything else, the bottleneck will simply move to one of the other components.

The only way you can avoid the bottleneck and guarantee QoS in this case is by controlling the amount of resources each and every transaction takes… whether the resources are CPU or IO. It doesn’t matter if your problem is CPU or IO – MoreVRP will allow you to safeguard your QoS and SLA. Until today there doesn’t seem to be an overall solution to eliminate the bottleneck… but by using MoreVRP, you can make sure that it doesn’t affect your most critical transactions. No matter if you are working with SSDs or good old physical disks.

Something to think about the next time you consider buying a new storage device.

Cheers.

 

Posted in Conceptual, Technical | Tagged | Leave a comment

MoreVRP Keeps your SQL Server DB in Shape without Cramping your Business Users

Posted on 27/12/2010 by Irad Deutsch

We all know that the secret to staying healthy and fit depends on regular, routine exercise and good maintenance habits.  The same is true for our database.  But how can we ensure that our routine database workouts not interfere with or delay our business?

Throughout the work week different end-users interact with the database to conduct their urgent business activities. They insert new data and run numerous varied complex transactions using a variety of applications that combine and integrate data from different sources.  Sales teams enter new customer and pricing data; engineering teams change product attributes and configurations.  Logistics clerks repeatedly update the database with RFID devices that transmit loads of status information from the warehouse.  Consuming this varied and heavy diet while running back and forth and at the same time concentrating on difficult calculations would give anyone indigestion, especially our MS SQL Server database, with its very sensitive stomach, special dietary requirements and lean frame….

So each week we invite our SQL Server database to the fitness center for a long workout.  The DBA carefully goes through the checklist, executing index and stats maintenance procedures, checking for index fragmentation or duplication that are likely to tire the database and slow it down.

Usually the DBA carries out the weekly maintenance routine on the weekend when fewer end-users need the database active.  Nevertheless, we all recall the times that the database hasn’t finished its maintenance workout on-time, causing many anxious end-users to congregate around the coffee machines on Monday morning waiting for the tired database to let them get their new work week started.

What can you do to empower your database to better mobilize its resources in order to carry out all the urgent business tasks you need to do in parallel to its time-consuming yet vital maintenance routines?  More IT offers you the unique wonder drug that will revitalize your database – MoreVRP!  Only MoreVRP, sometimes referred to as “APM on Steroids”, can get inside the database to reallocate its resources and prevent the loads that cause database indigestion, letting it concurrently execute end-user transactions while more slowly doing its maintenance routines without interrupting your business.

There are many vendors that offer a wealth of health check monitors that will measure how tired your database is, as well as sophisticated exercise machines that let your DBAs assign more and more routine exercises and training to keep your database fit.

Only MoreVRP gives your SQL Server db the resource management “muscle” you need to keep your business going strong!   For more details, check out our solution on www.morevrp.com

 

Posted in Conceptual | Tagged , , , , , | Leave a comment

Taking virtualization to the transaction level… is it possible ?

Posted on 04/12/2010 by Irad Deutsch

If you look around you, virtualization is everywhere. We have virtual offices, virtual phone numbers, virtual reality… and virtual machines.

The acceptance of virtual machines has evolved so rapidly you can find them almost anywhere, from small offices to large enterprises. Even CIOs who are considered to be very conservative have by now migrated some of their enterprise applications to virtual environments in order to cut costs and increase productivity.

However, virtualization still has one big drawback… until now it seems that virtual machines can deliver only virtual QoS and SLA.

Here is a scenario to illustrate:

Let’s say we have a CRM application serving 10,000 users and running on a virtual machine. The CEO wants to run a report that needs to scan five years of data. So now we have one extremely large transaction running in the system and consuming an enormous amount of CPU and IO.  And as this is the CEO we are talking about, he certainly expects this report to run as fast as possible.

Let’s say that the system suddenly becomes very busy, and the CPU reaches 100%. This triggers the VM management system to kick in and allocate more physical CPUs to this system in order to comply with the high demand for CPU power.

So the VM system adds more CPU power to the entire operating system, but what is the result?  Each transaction running in the system now runs a little bit faster. But this doesn’t achieve the effect we wanted, which was to allocate significantly more resources specifically to the CEO’s report so that it would finish right away.

This is where MoreVRP comes in to the picture, offering the ability to allocate resources at the transaction level. At many of our customers’ sites, MoreVRP works on top of a virtual machine within a virtual environment;  it can be easily integrated in any VM environment.

MoreVRP allows you to make sure that the resources you add are allocated effectively, to those transactions you really want to accelerate, not across all transactions. This is truly dynamic resource management at the transaction level. You can create these kind of interactions between Virtual Machines and MoreVRP using the “MoreVRP integration pack” module.

By the way – it works also the other way around. When you need to take some resources away from a specific VM (because there is high demand for resources from another VM) you want to make sure that the critical transactions’ QoS and SLA will remain high. MoreVRP guarantees stable QoS for your critical transactions within the VM.

This is the real power of virtualization at the transaction level. This is the power of MoreVRP.

Cheers.

 

Posted in Conceptual | Tagged , , , , , , , , | Leave a comment

Upgrades and migrations – must they involve a risk to database performance?

Posted on 15/11/2010 by Irad Deutsch

One of the tasks DBAs hate the most is that of database upgrades and migrations.  A database upgrade is one of the most complicated projects an organization faces. It involves architectural changes, physical and logical modifications to the data layout, and these changes create a great risk to database performance, which of course impact all the applications that rely on that database and all the end-users that rely on those applications.

When it comes to upgrades – there are three types of upgrades :

  • A database version upgrade (such as upgrading from MS SQLServer 2005 to 2008);
  • A schema upgrade – A change to the logical layout of the data, tables structure , indexes  etc. (such as a database upgrade driven by an upgrade of an application using that database); or
  • A hardware & environment upgrade – A change to the physical layout of the database – upgrading the IO subsystem, adding CPUs or changing the Operating System version (such as applying a Red Hat patch, or adding more RAM to your server).

The database engine is not just a black box; moreover it possesses intelligent processing capabilities.  It has the ability to automatically adjust itself to environmental changes and to run queries differently as a consequence of those environmental changes…  For example, if it detects that there is more CPU power available, it will try to change the way that it runs a given query to better utilize the added CPU power.   On the other hand, if it notes that the memory has been reduced, it will automatically try to locate more IO on the disk to compensate for the loss of memory.

So any of these changes may cause differences in DB behavior. Especially if you make a change in an application and the way it works.

No matter what kind of upgrade you are planning, you are likely to face some performance problems at some level… even if you are just adding more CPU power.

This is where MoreVRP comes to the rescue.  MoreVRP Enterprise Edition 4 has a very unique feature that allows DBAs to easily identify transactions whose behavior has changed due to upgrades or environmental changes.

This feature is part of our Variance & Analytics module.  You can read more about it here:  http://www.more-resource.com/content.php?id=142

These graphs allow you to compare different time frames and isolate only those queries that behave differently. Whether they use more CPU, more IO or maybe they run for longer periods of time than they did before, MoreVRP will point them out for you so that you can focus your attention on solving the problem rather than looking for it.

So the next time someone tells you that upgrades are risky, tell them that they can reduce the risk dramatically by using the Variance Graphs in MoreVRP.  They work like magic!

Cheers

 

Posted in Technical | Tagged , , , , , , , | Leave a comment