Puppet is a configuration management tool that can be used to great advantage managing the configurations of a large fleet of servers in an enterprise.

My first thought upon finishing Turnbull & McCune's book was that it could well have been titled Pro Deployments, for it covers a whole host of topics, integrating Puppet with a lot of other related tools.

Some of the advanced topics it covers in depth include:

• integrating Puppet with version control such as git
• setup of the standard dev, test and production environments
• conditional application of generalized configs
• managing nagios & load balancer configs to automatically add new nodes
• capitalizing on puppet forge modules (like rpm packages)
• testing your puppet configs with cucumber
• reporting with the dashboard and the command line

I found it a strong title overall, well written, technical and broad brushed.  Unfortunately I found it sorely lacking in a few areas that I would consider of growing  importance everyday.

• How can I use puppet for managing cloud hosted servers?
• How does Puppet compare to other solutions such as Chef?
• What parts of Puppet itself needs to be backed up and how do I do that?

I also found the discussion of Puppet in a real-time configuration with Marionette Colective was a bit short on details.

Furthermore I have one rather large and nagging question for real world usage and deployments.  There are often times when troubleshooting production systems where you need to dig into configs, and make a change instantly, for instance on a running MySQL server.   How can I do that in a managed way?  Should I put Puppet into manual mode and only push configs when I ask it to?  How about if I want to manage upgrades of a database carefully such as with Oracle, as those can be quite temperamental - how should that process be managed?  How do I prevent crucial production servers from being restarted accidentally?

It would be nice to see a lengthy discussion of these real-world operational questions, but at least for the time being I'll look to google and various forums for answers.

Link to my full review on Amazon

I meet new people all the time.  It's a way of life in New York.  One of the first questions new people ask each other is "What do you do?".  It begins to sound like a cliche after a while, but it can also provide endless fascinating discussions as there are so many people with different professions in New York.  Some choose a titled answer "i'm an investment banker", "I'm an emcee", "I'm an executive recruiter".  I find for "Web Scalability Consultant" or "Web Operations Expert" this only leaves confused looks.

A Plumber By Another Name

The solution of course is to tell a good story.  Stories illustrate what titles and crusty vernacular cannot.  I've used analogies to surgeons or mechanics, of course they all operate on something people can related to in front of them.  People or vehicles we use everyday.  Of course with the internet, there is a huge hidden infrastructure that most people don't see everyday.  They may vaguely know it's there, but it's still hidden out of site.

That's why I think plumbing provides such an apt visual.  As it turns out the internet is built with countless data pipes both large and small, coming into your home or laying across the bottom of the transatlantic ocean.  These pipes plug into routers, high speed traffic lights and traffic cops.  Ultimately they feed into datacenters, huge rooms filled with racks of computers, holding your websites crown jewels.  Therein contains the images and status updates from your facebook profile, your banking transactions from your personal bank account or credit card, your netflix movie stream, or the email you sent via gmail.  Even your instant messaging stream, or the data from your favorite iphone app are all stored and retrieved from here.

Amazon Outage

The recent Amazon outage has been high profile enough that a lot of folks who don't follow the latest trends in web operations, devops, and datacenter automation still heard about this event.  Turns out it's had a silver lining for Amazon cause now everyone is scrutinizing how many sites actually rely on this goliath of a hosting provider.

As it turns out the root of the amazon outage was indeed a plumbing problem.  Amazon has shown rather high transparency publishing intimate details of the problem and it's resolution.  Read more.

A misconfigured network cascaded through the system creating countless failures.  If you imagine water repairs being done in a large New York City building, they often ask tenants to turn off their water, so they won't all come on at the same time when service is restored.  SImilarly intricate problems complicated the Amazon effort, slowing down attempts to restore everything after the incident.  I wrote at length about the outage if you're interested, read more.

BOOK REVIEW:  Game-Based Marketing by Zicherman & Linder

There are so many new books coming out all the time, it's tough to sift and find the good ones.  Anyone with a website as their storefront, whether they are a product company or a services company, can gain from reading this book.

From leaderboards to frequent flyer programs, badges and more this book is full of real-world examples where game-based principles are put into action.  On the internet where attention is a rarer and rarer commodity, these concepts will surely make a big difference to your business.

Amazon book link - Game Based Marketing

Now that we've had a chance to take a deep breath after last week's AWS outage, I'll offer some comments of my own.  Hopefully just enough time has passed to begin to have a broader view, and put events in perspective.
Despite what some reports may have announced, Amazon wasn't down, but rather a small part of Amazon Web Services went down.  A failure, yes.  Beyond their service level agreement of 99.95% yes also.  Survivable, yes to this last question too.

Learning From Failure

The business management conversation du jour is all about learning from failure, rather than trying to avoid it.  Harvard Business Review's April issue headlined with "The Failure Issue - How to Understand It, Learn From It, and Recover From It".  The economist's April 16th issue had some similarly interesting pieces one by Schumpeter "Fail often, fail well",
and another in April 23rd issue "Lessons from Deepwater Horizon and Fukushima".
With all this talk of failure there is surely one takeaway.  Complex systems will fail and it is in the anticipation of that failure that we gain the most.  Let's stop howling and look at how to handle these situations intelligently.

How Do You Rebuild A Website?

In the cloud you will likely need two things.  (a) scripts to rebuild all the components in your architecture, spinup servers, fetch source code, fetch software and configuration files, configure load balancers and mount your database and more importantly (b) a database backup from which you can rebuild your current dataset.

Want to stick with EC2, build out your infrastructure in an alternate availability zone or region and you're back up and running in hours.  Or better yet have an alternate cloud provider on hand to handle these rare outages.  The choice is yours.

Mitigate risk?  Yes indeed failure is more common in the cloud, but recovery is also easier.  Failure should pressure the adoption of best practices and force discipline in deployments, not make you more of a gunslinger!

Want to see an extreme example of how this can play in your favor?  Read Jeff Atwood's discussion of so-called Chaos Monkey, a component whose sole job it is to randomly kill off servers in the Netflix environment at random.  Now that type of gunslinging will surely keep everyone on their toes!  Here's a Wired article that discusses Chaos Monkey.

George Reese of enStratus discusses the recent failure at length.  The I would argue calling Amazon's outage the Cloud's Shing Moment, all of his points are wisened and this is the direction we should all be moving.

Going The Way of Commodity Hardware

Though it is still not obvious to everyone, I'll spell it out loud and clear.  Like it or not, the cloud is coming.  Look at these numbers.

Furthermore the recent outage also highlights how much and how many internet sites rely on cloud computing, and Amazon EC2.
Way back in 2001 I authored a book on O'Reilly called "Oracle and Open Source".  In it I discussed the technologies I was seeing in the real world.  Oracle on the backend and Linux, Apache, and PHP, Perl or some other language on the frontend.  These were the technologies that startups were using.  They were fast, cheap and with the right smarts reliable too.

Around that time Oracle started smelling the coffee and ported it's enterprise database to Linux.  The equation for them was simple.  Customers that were previously paying tons of money to their good friend and confidant Sun for hardware, could now spend 1/10th as much on hardware and shift a lot of that left over cash to - you guessed it Oracle!  The hardware wasn't as good, but who cares because you can get a lot more of it.

Despite a long entrenched and trusted brand like Sun being better and more reliable, guess what?  Folks still switched to commodity hardware.  Now this is so obvious, no one questions it.  But the same trend is happening with cloud computing.

Performance is variable, disk I/O can be iffy, and what's more the recent outage illustrates front and center, the servers and network can crash at any moment.  Who in their right mind would want to move to this platform?

If that's the question you're stuck on, you're still stuck on the old model.  You have not truely comprehended the power to build infrastructure with code, to provision through automation, and really embrace managing those components as software.  As the internet itself has the ability to route around political strife, and network outages, so too does cloud computing bring that power to mom & pop web shops.

Conclusions

• Have existing investments in hardware?  Slow and cautious adoption makes most sense for you.

• Have seasonal traffic variations?  An application like this is uniquely suited to the cloud.  In fact some of the gaming applications which can autoscale to 10x or 100x servers under load, are newly solveable with the advent of cloud computing.

• Are you currently paying a lot for disaster recovery systems that primarily lay idle.  Script your infrastructure for rebuilding from bare metal, and save that part of the budget for more useful projects.

Cloud Computing may not make sense for all application types.  But as with the adoption of commodity hardware and Linux over a decade ago, economic considerations will continue to pressure adoption.

** Original article -- Intro to EC2 Cloud Deployments **

What types of applications do fit well in the cloud?

1. Applications with Seasonal Traffic Patterns

1. Proof-of-concept Applications

1. Quick Temporary Dev & Test Environments

1. CPU Intensive Applications

1. On-Demand or Unknown Future Demand

Seasonal Traffic Patterns

With traditional managed hosting solutions, we have best practices, we have business continuity plans, we have disaster recovery, we document our processes and all the moving parts in our infrastructure.  At least we pay lip service to these goals, though from time to time we admit to getting side tracked with bigger fish to fry, high priorities and the emergency of the day.  We add "firedrill" to our todo list, promising we'll test restoring our backups.  But many times we find it is in the event of an emergency that we are forced to find out if we actually have all the pieces backed up and can reassemble them properly.

** Original article -- Intro to EC2 Cloud Deployments **

Cloud Computing is different.  These goals are no longer be lofty ideals, but must be put into practice.  Here's why.

1. Virtual servers are not as reliable as physical servers
2. Amazon EC2 has a lower SLA than many managed hosting providers
3. Devops introduces new paradigm, infrastructure scripts can be version controlled
4. EC2 environment really demands scripting and repeatability
5. New flexibility and peace of mind

Unreliable Servers

EC2 virtual servers can and will die.  Your spinup scripts and infrastructure should consider this possibility not as some far off anomalous event, but a day-to-day concern.  With proper scripts and testing of various scenarios, this should become manageable.  Use snapshots to backup EBS root volumes, and build spinup scripts with AMIs that have all the components your application requires.  Then test, test and test again.

Amazon EC2's SLA - Only 99.95%

The computing industry throws around the 99.999% or five-nines uptime SLA standard around a lot.  That amounts to less than six minutes of downtime.  Amazon's 99.95% allows for 263 minutes of downtime.  Greater downtime merely gets you a credit on your account.  With that in mind, repeatable processes and scripts to bring your infrastructure back up in different availability zones or even different datacenters is a necessity.  Along with your infrastructure scripts, offsite backups also become a wise choice.  You should further take advantage of availability zones and regions to make your infrastructure more robust.  By using private IP addresses and network, you can host a MySQL database slave in a separate zone, for instance.  You can also do GDLB or Geographically Distributed Load Balancing to send customers on the west coast to that zone, and those on the east coast to one closer to them.  In the event that one region or availability zone goes out, your application is still responding, though perhaps with slightly degraded performance.

Devops - Infrastructure as Code

With traditional hosting, you either physically manage all of the components in your infrastructure, or have someone do it for you.  Either way a phone call is required to get things done.  With EC2, every piece of your infrastructure can be managed from code, so your infrastructure itself can be managed as software.  Whether you're using waterfall method, or agile as your software development lifecycle, you have the new flexibility to place all of these scripts and configuration files in version control.  This raises manageability of your environment tremendously.  It also provides a type of ongoing documentation of all of the moving parts.  In a word, it forces you to deliver on all of those best practices you've been preaching over the years.

EC2 Environment Considerations

When servers get restarted they get new IP addresses - both private and public.  This may affect configuration files from webservers to mail servers, and database replication too, for example.  Your new server may mount an external EBS volume which contains your database.  If that's the case your start scripts should check for that, and not start MySQL until it finds that volume.  To further complicate things, you may choose to use software raid over a handful of EBS volumes to get better performance.

The more special cases you have, the more you quickly realize how important it is to manage these things in software.  The more the process needs to be repeated, the more the scripts will save you time.

New Flexibility in the Cloud

Ultimately if you take into consideration less reliable virtual servers, and mitigate that with zones and regions, and automated scripts, you can then enjoy all the new benefits of the cloud.

• autoscaling
• easy test & dev environment setup
• robust load & scalability testing
• vertically scaling servers in place - in minutes!
• pause a server - incurring only storage costs for days or months as you like
• cheaper costs for applications with seasonal traffic patterns
• no huge up-front costs

Migrating from MySQL to Oracle can be as complex as picking up your life and moving from the country to the city.  Things in the MySQL world are often just done differently than they are in the Oracle world.  Our guide will give you a birds eye view of the differences to help you determine what is the right path for you.

** See also: Oracle to MySQL Migration Considerations **

MySQL comes from a more open-source or DIY background.  One of Unix and Linux administrators and even developers carrying the responsibility of a DBA.

1. Installation & Administration Considerations
2. Query and Optimizer Differences
3. Security Strengths and Weaknesses
4. Replication & High Availability
5. Table Types & Storage Engines
6. Applications, Connection Pooling, Stored Procedures and More
7. Backups & Disaster Recovery
8. Community - MySQL & Oracle Differences
9. TCO, Licensing, and Cloud Considerations
10. Advanced Oracle Features - Missing in MySQL

Check back soon as we update each of these sections.

There are a lot of forms of transportation, from walking to bike riding, motorcycles and cars to busses, trains and airplanes.  Each mode of transport will get you from point a to point b, but one may be faster, or more comfortable and another more cost effective.  It's important to keep in mind when comparing databases like Oracle and MySQL that there are indeed a lot of feature differences, a lot of cultural differences, and a lot of cost differences.  There are also a lot of impassioned people on both sides arguing at the tomfoolery of the other.  Hopefully we can dispel some of the myths and discuss the topic fairly.

** See also: Migrating MySQL to Oracle Guide **

As a long time Oracle DBA turned MySQL expert, I've spent time with clients running both database engines and many migrating from one to the other.  I can speak to many of the differences between the two environments.  I'll cover the following:

1. Query & Optimizer Limitations
2. Security Differences
3. Replication & HA Are Done Differently
4. Installation & Administration Simplicity
5. Watch Out - Triggers, Stored Procedures, Materialized Views & Snapshots
6. Huge Community Support - Open-source Add-ons
7. Enter The Cloud With MySQL
8. Backup and Recovery
9. Miscellaneous Considerations

Check back again as we edit and publish the various sections above.

Scalability in the cloud depends a lot on application design.  Keep these important points in mind when you are designing your web application and you will scale much more naturally and easily in the cloud.

** Original article -- Intro to EC2 Cloud Deployments **

1. Think twice before sharding

• It increases your infrastructure and application complexity
• it reduces availability - more servers mean more outages
• have to worry about globally unique primary keys

2. Bake read/write database access into the application

• allows you to check for stale data, fallback to write master
• creates higher availability for read-only data
• gracefully degrade to read-only website functionality if master goes down
• horizontal scalability melds nicely with cloud infrastructure and IAAS

3. Save application state in the database

• avoid in-memory locking structures that won't scale with multiple web application servers
• consider a database field for managing application locks
• consider stored procedures for isolating and insulating developers from db particulars
• a last updated timestamp field can be your friend

4. Consider Dynamic or Auto-scaling

• great feature of cloud, spinup new servers to handle load on-demand
• lean towards being proactive rather than reactive and measure growth and trends
• watch the procurement process closely lest it come back to bite you

5. Setup Monitoring and Metrics

• see trends over time
• spot application trouble and bottlenecks
• determine if your tuning efforts are paying off
• review a traffic spike after the fact

The cloud is not a silver bullet that can automatically scale any web application.  Software design is still a crucial factor.  Baking in these features with the right flexibility and foresight, and you'll manage your websites growth patterns with ease.

Have questions or need help with scalability?  Call us:  +1-212-533-6828

Cloud Computing holds a lot of promise, but there are also a lot of speed bumps in the road along the way.

In this six part series we're going to cover a lot of ground.  We don't intend this series to be an overly technical nuts and bolts howto.  Rather we will discuss high level issues and answer questions that come up for CTOs, business managers, and startup CEOs.

Some of the tantalizing issues we'll address include:

• How do I make sure my application is built for the cloud with scalability baked into the architecture?
• I know disk performance is crucial for my database tier.  How do I get the best disk performance with Amazon Web Services & EC2?
• How do I keep my AWS passwords, keys & certificates secure?
• Should I be doing offsite backups as well, or are snapshots enough?
• Cloud providers such as Amazon seem to have poor SLAs (service level agreements).  How do I mitigate this using availability zones & regions?
• Cloud hosting environments like Amazons provide no perimeter security.  How do I use security groups to ensure my setup is robust and bulletproof?
• Cloud deployments change the entire procurement process, handing a lot of control over to the web operations team.  How do I ensure that finance and ops are working together, and a ceiling budget is set and implemented?
• Reliability of Amazon EC2 servers is much lower than traditional hosted servers.  Failure is inevitable.  How do we use this fact to our advantage, forcing discipline in the deployment and disaster recovery processes?  How do I make sure my processes are scripted & firedrill tested?
• Snapshot backups and other data stored in S3 are somewhat less secure than I'd like.  Should I use encryption to protect this data?  When and where should I use encrypted filesystems to protect my more sensitive data?
• How can I best use availability zones and regions to geographically disperse my data and increase availability?

As we publish each of the individual articles in this series we'll link them to the titles below.  So check back soon!

1. Building Highly Scalable Web Applications for the Cloud
2. Managing Security in Amazon Web Services
3. MySQL Databases in the Cloud - Best Practices
4. Backup and Recovery in the Cloud - A Checklist
5. Cloud Deployments - Disciplined Infrastructure
6. Cloud Computing Use Cases

Believe it or not you can actually start playing around with virtual servers that are as real and powerful as the physical servers you're already used to deploying.  And you can do it for literally pennies per month.

1. Signup for an Amazon account or use the one you buy books with.
2. Browse over to http://aws.amazon.com & click Sign Up Now
3. Navigate to AWS Management Console, follow the Amazon EC2 link, and click Launch Instance
4. Download Elastic Fox or the API tools & configure your credentials for easy browser or command line control of your virtual infrastructure and deployments.
5. Terminate instances & delete volumes & snapshots so you'll have no recurring charges.

At a mere 8 and 1/2 cents per hour, you can play around with the technology with no real ongoing costs.  And you can do it with your existing Amazon account and credit card info.

Good stuff!

Your website is slow but you're not sure why.  You do know that it's impacting your business.  Are you losing customers to the competition? Here are five quick tips to achieve scalability

1. Gather Intelligence

With any detective work you need information.  That's where intelligence comes in.  If you don't have the right data already, install monitoring and trending systems such as Cacti and Collectd.  That way you can look at where your systems have been and where they're going.

2. Identify Bottlenecks

Put all that information to use in your investigation.  Use stress testing tools to hit areas of the application, and identify which ones are most troublesome.  Some pages get hit A LOT, such as the login page, so slowness there is more serious than one small report that gets hit by only  a few users.  Work on the biggest culprits first to get the best bang for your buck.

3. Smooth Out the Wrinkles

Reconfigure your webservers to make more connections to your database, or spin-up more servers.  On the database tier make sure you have fast RAIDed disk, and lots of memory.  Tune queries coming from your application, and look at possible upgrades to servers.

4. Be Agile But Plan for the Future

Can your webserver tier scale horizontally?  Pretty easy to add more servers under a load balancer.  How about your database.  Chances are with a little work and some HA magic your database can scale out with more servers too, moving the bulk of select operations to read-only copies of your primary server, while letting it focus on transactions, and data updates.  Be ready and tested so you know exactly how to add servers without impacting the customers or application.  Don't know how?  Look at the big guys like Facebook, an investigate how they're doing it.

5. A Going Concern

Most importantly, just like your business, your technology infrastructure is an ongoing work in progress.  Stay proactive with monitoring, analysis, trending, and vigilance.  Watch application changes, and filter for slow queries.  Have new hardware or additional hardware dynamically at-the-ready for when you need it.

You've heard all about twitter, and you may have visited the website, or used it through other tools that bring your messages from linkedin or facebook into twitter.  It turns out there is a lot more to the twitter world that first meets the eye.

1. Make regular and relevant use of hashtags

2. Focus on your subject matter expertise

3. Monitor trends on google and twitter.com

4. Link to colleagues you respect and promote cross-pollination of networks.

5. Remember you are broadcasting, so word your tweets appropriate to your audience.

1. What is the difference between RMAN and a traditional hotbackup?

RMAN is faster, can do incremental (changes only) backups, and does not place tablespaces into hotbackup mode.

2. What are bind variables and why are they important?

With bind variables in SQL, Oracle can cache related queries a single time in the SQL cache (area). This avoids a hard parse each time, which saves on various locking and latching resources we use to check objects existence and so on. BONUS: For rarely run queries, especially BATCH queries, we explicitely DO NOT want to use bind variables, as they hide information from the Cost Based Opitmizer.

BONUS BONUS: For batch queries from 3rd party apps like peoplesoft, if we can't remove bind variables, we can use bind variable peeking!

3. In PL/SQL, what is bulk binding, and when/how would it help performance?

Oracle's SQL and PL/SQL engines are separate parts of the kernel which require context switching, like between unix processes. This is slow, and uses up resources. If we loop on an SQL statement, we are implicitely flipping between these two engines. We can minimize this by loading our data into an array, and using PL/SQL bulk binding operation to do it all in one go!

4. Why is SQL*Loader direct path so fast?

SQL*Loader with direct path option can load data ABOVE the high water mark of a table, and DIRECTLY into the datafiles, without going through the SQL engine at all. This avoids all the locking, latching, and so on, and doesn't impact the db (except possibly the I/O subsystem) at all.

5. What are the tradeoffs between many vs few indexes? When would you want to have many, and when would it be better to have fewer?

Fewer indexes on a table mean faster inserts/updates. More indexes mean faster, more specific WHERE clauses possibly without index merges.

6. What is the difference between RAID 5 and RAID 10? Which is better for Oracle?

RAID 5 is striping with an extra disk for parity. If we lose a disk we can reconstruct from that parity disk.

RAID 10 is mirroring pairs of disks, and then striping across those sets.

RAID 5 was created when disks were expensive. Its purpose was to provide RAID on the cheap. If a disk fails, the IO subsystem will perform VERY slowly during the rebuild process. What's more your liklihood of failure increases dramatically during this period, with all the added weight of the rebuild. Even when it is operating normally RAID 5 is slow for everything but reading. Given that and knowing databases (especially Oracle's redo logs) continue to experience write activity all the time, we should avoid RAID5 in all but the rare database that is MOSTLY read activity. Don't put redologs on RAID5.

RAID10 is just all around goodness. If you lose one disk in a set of 10 for example, you could lose any one of eight other disks and have no troubles. What's more rebuilding does not impact performance at all since you're simply making a mirror copy. Lastly RAID10 perform exceedingly well in all types of databases.

7. When using Oracle export/import what character set concerns might come up? How do you handle them?

Be sure to set NLS_LANG for example to "AMERCIAN_AMERICA.WE8ISO8859P1". If your source database is US7ASCII, beware of 8-bit characters. Also be wary of multi-byte characters sets as those may require extra attention. Also watch export/import for messages about any "character set conversions" which may occur.

8. How do you use automatic PGA memory management with Oracle 9i and above?

Set the WORKAREA_SIZE_POLICY parameter to AUTO and set PGA_AGGREGATE_TARGET

9. Explain two easy SQL optimizations.

a. EXISTS can be better than IN under various conditions

b. UNION ALL is faster than UNION (not sorting)

10. Name three SQL operations that perform a SORT.

a. CREATE INDEX

b. DISTINCT

c. GROUP BY

d. ORDER BY

f. INTERSECT

g. MINUS

h. UNION

i. UNINDEXED TABLE JOIN

11. What is your favorite tool for day-to-day Oracle operation?

Hopefully we hear some use of command line as the answer!

12. What is the difference between Truncate and Delete? Why is one faster?

Can we ROLLBACK both? How would a full table scan behave after?

Truncate is nearly instantaenous, cannot be rolled back, and is fast because Oracle simply resets the HWM. When a full table scan is performed on a table, such as for a sort operation, Oracle reads to the HWM. So if you delete every single solitary row in 10 million row table so it is now empty, sorting on that table of 0 rows would still be extremely slow.

13. What is the difference between a materialized view (snapshot) fast refresh versus complete refresh? When is one better, and when the other?

Fast refresh maintains a change log table, which records change vectors, not unlike how the redo logs work. There is overhead to this, as with a table that has a LOT of indexes on it, and inserts and updates will be slower. However if you are performing refreshes often, like every few minutes, you want to do fast refresh so you don't have to full-table-scan the source table. Complete refresh is good if you're going to refresh once a day. Does a full table scan on the source table, and recreats the snapshot/mview. Also inserts/updates on the source table are NOT impacted on tables where complete refresh snapshots have been created.

14. What does the NO LOGGING option do? Why would we use it? Why would we be careful of using it?

It disables the logging of changes to the redologs. It does not disable ALL LOGGING, however as Oracle continues to use a base of changes, for recovery if you pull the plug on the box, for instance. However it will cause problems if you are using standby database. Use it to speed up operations, like an index rebuild, or partition maintenance operations.

15. Tell me about standby database? What are some of the configurations of it? What should we watch out for?

Standby databases allow us to create a copy of our production db, for disaster recovery. We merely switch mode on the target db, and bring it up as read/write. Can setup as master->slave or master->master. The latter allows the former prod db to become the standby, once the failure cause is remedied. Watch out for NO LOGGING!! Be sure we're in archivelog mode.

One of the more popular articles on our site according to Google is the Oracle DBA Interview Questions article we did a few years ago. So with that in mind, we've put together a similar article for MySQL DBA Interviews.

1. Explain two ways that MySQL Replication can get out of sync. What are the solutions to these problems?

One way is if your code contains non-deterministic functions such as SYSDATE, USER and UUID. The second way is if you have mixed transactions between InnoDB and MyISAM tables, in some cases those can get replicated incorrectly.

2. How does one create a new user and give it privileges on an existing database? Why should "with grant option" be avoided?

mysql> grant all privileges on test.* to 'newuser'@'localhost' identified by 'mypassword';

3. Explain the differences, advantages and disadvantages to using the MERGE storage engine, versus using Partitioned tables to manage large datasets.

The MERGE storage behaves much like a view with UNION ALL between the tables. It is easy to add and remove tables and redefine the MERGE table. They are good for logging and huge datasets.

One of the primary differences between partitioning is that a row can exist in one and only one partition, which is not the case with a MERGE table. Also you can cluster data together in certain partitions reducing the amount of work the server may have to do to get at related data. Also partitioned data can be distributed across multiple harddrives.

4. How do you determine what storage engines are installed?

mysql> show global variables like 'have%';                                       
+-----------------------+----------+
| Variable_name         | Value    |
+-----------------------+----------+
| have_archive          | NO       |
| have_bdb              | YES      |
| have_blackhole_engine | NO       |
| have_compress         | YES      |
| have_crypt            | YES      |
| have_csv              | NO       |
| have_dynamic_loading  | YES      |
| have_example_engine   | NO       |
| have_federated_engine | NO       |
| have_geometry         | YES      |
| have_innodb           | YES      |
| have_isam             | NO       |
| have_merge_engine     | YES      |
| have_ndbcluster       | NO       |
| have_openssl          | DISABLED |
| have_query_cache      | YES      |
| have_raid             | NO       |
| have_rtree_keys       | YES      |
| have_symlink          | YES      |
+-----------------------+----------+
19 rows in set (0.00 sec)
mysql>

5. How do you get the query cache status? How do you tune it?

mysql> show global status like 'qcache%';                                        
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Qcache_free_blocks      | 0     |
| Qcache_free_memory      | 0     |
| Qcache_hits             | 0     |
| Qcache_inserts          | 0     |
| Qcache_lowmem_prunes    | 0     |
| Qcache_not_cached       | 0     |
| Qcache_queries_in_cache | 0     |
| Qcache_total_blocks     | 0     |
+-------------------------+-------+
8 rows in set (0.16 sec)
mysql>

Tune it by looking at qcache_hits/(qcache_hits+com_selects)

6. What is DRBD?  Explain the advantages and disadvantages to MySQL Replication for High Availability.

7. What is circular replication?  How is it different from master-slave replication?

The karma project is no longer maintained.

If you'd like more information about Oracle Consulting please visit our Oracle Professional Services page.

The beauty of reading a book by a publisher not sanctioned by Oracle and by an author who doesn't work for Oracle is that they can openly mention bugs. And there are oh-so-many! This book is a superb introduction to the Cost Based Optimizer, and is not afraid to discuss it's many shortcomings. In so doing it also explains how to patch up those shortcomings by giving the CBO more information, either by creating a histogram here and there, or by using the DBMS_STATS package to insert your own statistics in those specific cases where you need to.

Another interesting thing is how this book illustrates, though accidentally, the challenges of proprietary software systems. Much of this book and the authors time is spent reverse engineering the CBO, Oracle's bread and butter optimizing engine. Source code, and details about its inner workings are not published or available. And of course that's intentional. But what's clear page after page in this book is that for the DBA and system tuner, going about their day to day tasks, they really need inside information about what the optimizer is doing, and so this book goes on a long journal to illuminate much of what the CBO is doing, or in some cases provide very educated guesses and some speculation. In contrast, as we know and hear about often, the Open Source alternative provides free access to source code, though not necessarily to the goods themselves. What this means in a very real way is that a book like this would not need to be written for an alternative open source application, because the internal code would be a proverbial open book. That said it remains difficult to imagine how a company like Oracle might persue a more open strategy given that their bread and butter really is the secrets hidden inside their Cost Based Optimizing engine. At any rate, let's get back to Jonathan's book.

Reading this book was like reading a scientists notebook. I found it:

o of inestimable value, but sometimes difficult to sift through

o very anecdotal in nature, debugging, and constantly demonstrating that the CBO is much more faulty and prone to errors than you might imagine

o may not be easy to say I have a query of type X, and it is behaving funny, how do I lookup information on this?

o his discussion of the evolution of the product is so good I'll quote it:

"A common evolutionary path in the optimizer code seems to be the following: hidden by undocumented parameter and disabled in first release; silently enabled but not costed in second release; enabled and costed in third release."

o has excellent chapter summaries which were particularly good for sifting, and boiling down the previous pages into a few conclusions.

o it will probably be of particular value to Oracle's own CBO development teams

Chapter highlights

CH2 - Tablescans

explains how to gather system stats, how to use dbms_stats to set ind. stats manually, bind variables can make the CBO blind, bind variable peeking may not help, partition exchange may break global stats for table, use CPU costing when possible

CH3 - Selectivity

big problem with IN lists in 8i, fixed in 9i/10g, but still prob. with NOT IN, uses very good example of astrological signs overlapping birth months, and associated CBO cardinality problems, reminds us that the optimizer isn't actually intelligent per se, but merely a piece of software

CH4 BTree Access

cost based on depth, #leaf blocks, and clustering factor, try to use CPU costing (system statistics)

CH5 - Clustering Factor

mainly a measure of the degree of random distribution of your data, very important for costing indx scans, use dbms_stats to correct when necessary, just giving CBO better information, freelists (procID problem) + freelist groups discussion with RAC

CH6 - Selectivity Issues

there is a big problem with string selectivity, Oracle uses only first seven characters, will be even more trouble for urls all starting with "http://", and multibyte charactersets, trouble when you have db ind. apps which use string for date, use histrograms when you have problems, can use the tuning advisor for "offline optimization", Oracle uses transitive closure to transform queries to more easily opt versions, moves predicates around, sometimes runs astray

CH7 - Histograms

height balanced > 255 buckets (outside Oracle called equi-depth),

otherwise frequency histograms, don't use cursor sharing as it forces bind variables, blinds CBO, bind var peeking is only first call, Oracle doesn't use histograms much, expensive to create, use sparingly, dist queries don't pull hist from remote site, don't work well with joins, no impact if you're using bind vars, if using dbms_stats to hack certain stats be careful of rare codepaths

CH8 - Bitmap Indexes

don't stop at just one, avoid updates like the plague as can cause deadlocking, opt assumes 80% data tightly packed, 20% widely scattered

CH9 - Query Transformation

partly rule based, peeling the onion w views to understand complex queries, natural language queries often not the most efficient, therefore this transformation process has huge potential upside for Oracle in overall optimization of app code behind the scenes by db engine, always remember Oracle may rewrite your query, sometimes want to block with hints, tell CBO about uniqueness, not NULL if you know this

CH10 - Join Cardinality

makes sensible guess at best first table, continues from there,

don't hide useful information from the CBO, histograms may help with some difficult queries

CH11 - Nested Loops

fairly straightforward costing based on cardinality of each returned set multiplied together

CH12 - Hash Joins

Oracle executes as optimal (all in memory), onepass (doesn't quite fit so dumped to disk for one pass) and multipass (least attractive sort to disk), avoid scripts writing scripts in prod, best option is to use workarea_size_policy=AUTO, set pga_aggregate_target & use CPU costing

CH 13 - Sorting + Merge Joins

also uses optimal, onepass, & multipass algorithms, need more than 4x dataset size for in memory sort, 8x on 64bit system, increasing sort_area_size will incr. CPU util so on CPU bottlenecked machines sorting to disk (onepass) may improve performance, must always use ORDER BY to guarentee sorted output, Oracle may not need to sort behind the scenes, Oracle very good at avoiding sorts, again try to use workarea_size_policy=AUTO

CH 14 - 10053 Trace

reviews various ways to enable, detailed rundown of trace with comments inline, and highlights; even mentions a VOL 2 + 3 of the book is coming!

Appendix A

be careful when switching from analyze to dbms_stats, in 10g some new hist will appear w/default dbms_stats options, 10g creates job to gather stats

Conclusion

I found this book to be full of gems of information that you won't find anywhere else. If you're at the more technical end of the spectrum, this is a one of a kind Oracle book and a

must-have for your collection. Keep in mind something Jonathan mentions in appendix A: "New features that improve 99% of all known queries may cripple your database because you fall into the remaining 1% of special cases". If these cases are your concern, then this book will surely prove to be one-of-a-kind for you!

View this review on Amazon.com

I have a confession to make. I haven't read an Oracle book cover-to-cover in almost three years. Sure I skim through the latest titles for what I need and of course check out documentation of the latest releases. That's what good docs provide, quick reference when you need to check syntax, or details of a particular parameter, or feature, but have you ever read some documentation, sift through a paragraph, page or two, and say to yourself, that's great, but what about this situation I have right now? Unfortunately documentation doesn't always

speak to your real everyday needs. It is excellent for reference, but doesn't

have a lot of real-world test cases, and practical usage examples. That's where Tom Kyte's new book comes in, and boy is it a killer.

I've read Tom's books before, and always enjoyed them. But his new APress title really stands out as an achievement. Page after page and chapter after chapter he uses straightforward examples pasted right from the SQL*Plus prompt to illustrate, demonstrate, and illuminate concepts that he is explaining. It is this practical hands on, relentless approach that makes this book 700 pages of goodness.

Already an expert at Oracle? You'll become more of one after reading this book. With reviewers like Jonathan Lewis I expected this book to be good from the outset I have to admit. But each chapter delves into a bit more depth around subjects that are central to Oracle programming and administration.

No SCREEN SHOTS!

One of the things I loved about this book most of all is its complete lack of screenshots! But how does one illustrate a concept then, you might ask? These days with graphical interfaces becoming more and more popular even among technical folks, I run into the question of the command line over an over again. How can you be doing sophisticated database administration of the latest servers running Oracle with the command line? Or another question I often get is, can you really do everything with the command line? The answer to both is a resounding yes, in fact you can do much more with the command line. Luckily for us, Tom is of this school too, and page after page of his book are full of real examples and commands that you can try for yourself, with specific instructions on

setting up the environment, using statistics gathering packages, and so on. In an era of computing where GUIs seem to reign like magazines over the best literature of the day, it is refreshing to see some of the best and most technical minds around Oracle still advocate the best tool, command line as the interface

of choice. In fact it is the command line examples, and happily the complete lack of screenshots that indeed makes this book a jewel of a find.

Audience

As a DBA you might wonder why I'm talking so highly of a book more focused towards developers. There are a couple of reasons. First this book is about the Oracle architecture, as it pertains to developers. In order for developers to best take advantage of the enterprise investment in Oracle *** they need to thoroughly understand the architecture, how specific features operate, which features are appropriate, and how to optimize their code for best interaction with them. Of course a DBA who is trying to keep a database operating in tip top shape needs to be aware of when developers are not best using Oracle, to identify,

and bring attention to bottlenecks, and problem areas in the application. Second, it is often a DBAs job to tune an existing database, and the very largest benefits come from tuning application SQL. For instance if a developer has chosen to use a bitmap index on an INSERT/UPDATE intensive table, they're in for serious problems. Or if a developer forgot to index a foreign key column. This book directly spearheads those types of questions, and when necessary does mention a thing or two of direct importance to DBAs as well.

Highlights

Chapter 2 has an excellent example of creating an Oracle database. You simply write one line to your init.ora "db_name=sean" for example, and then from the SQL> prompt issues "startup nomount" and then "create database". Looking at the processes Oracle starts, and the files that are created can do wonders for your understanding of database, instance, and Oracle in general.

Chapter 3 covers files, files, and more files. Spfile replaces a text init.ora allowing parameters to be modified while an instance is running *AND* stored persistently. He covers redolog files, flashback logs, and change tracking file

s, as well as import/export dump files, and lastly datapump files.

Chapter 4 covers memory, and specifically some of the new auto-magic options, how they work, and what to watch out for.

Chapter 5 covers processes.

Chapter 6, 7, and 8 cover lock/latching, multiversioning, and transactions respectively. I mention them all here together because to me these chapters are the real meat of the book. And that's coming from a vegetarian! Seriously these

topics are what I consider to be the most crucial to understanding Oracle, and modern databases in general, and the least understood. They are the darkest corners, but Tom illuminates them for us. You'll learn about optimistic versus pessismistic locking, page level, row level, and block level locking in various modern databases such as SQLServer, Informix, Sybase, DB2 and Oracle. Note Oracle is by far in the lead in this department, never locking more than it needs to, which yields the best concurrency with few situations where users block each other. Readers never block, for instance, because of the way Oracle implements all of this. He mentions latch spinning, which Oracle does to avoid a context switch, that is more expensive, how to detect, and reduce this type of contention. You'll learn about dirty reads, phantom reads, and non-repeatable reads, and about Oracle's Read-committed versus Serializable modes. What's more you'll learn about the implications of these various models on your applications, and what type of assumptions you may have to unlearn if you're coming from developing on another database to Oracle. If I were to make any criticism at all, I might mention that in this area Tom becomes ever so slightly preachy about Oracle's superb implementation of minimal locking, and non-blocking reads. This is in large part due I'm sure to running into so many folks who are used to developing on databases which do indeed dumb you down *BECAUSE* of their implementation, encouraging bad habits with respect to transactions, and auto-commit for instance. One thing is for sure you will learn a heck of a lot from these three chapters, I know I did.

Chapter 9 Redo & Undo describes what each is, how to avoid checkpoint not complete and why you want to, how to *MEASURE* undo so as to reduce it, how to avoid log file waits (are you on RAID5, are your redologs on a buffered filesystem?), and what block cleanouts are.

Chapter 10 covers tables. After reading it I'd say the most important types are normal (HEAP), Index Organized, Temporary, and External Tables. Use ASSM where possible as it will save you in many ways, use DBMS_METADATA to reverse engineer objects you've created to get all the options, don't use TEMP tables to avoid inline views, or complex joins, your performance will probably suffer, and how to handle LONG/LOB data in tables.

Chapter 11 covers indexes, topics ranging from height, compression count, DESC sorted, colocated data, bitmap indexes and why you don't want them in OLTP data

bases, function based indexes and how they're most useful for user defined functions, why indexing foreign keys is important, and choosing the leading edge of an index. Plus when to rebuild or coalesce and why.

Chapter 12 covers datatypes, why never to use CHAR, using the NLS features, the CAST function, the number datatypes and precision versus performance, raw_to_hex, date arithmatic, handling LOB data and why not to use LONG, BFILEs and the new UROWID.

Chapter 13 discusses partitioning. What I like is he starts the chapter with the caveat that partitioning is not the FAST=TRUE option. That says it all. For OLTP databases you will achieve higher availability, and ease of administration of large options, as well as possibly reduced contention on larger objects,

but it is NOT LIKELY that you will receive query performance improvements because of the nature of OLTP. With a datawarehouse, you can use partition elimination on queries that do range or full table scans which can speed up queries dramatically. He discusses range, list, hash, and composite partitioning, local indexing (prefixed & non-prefixed) and global indexing. Why datawarehouses tend to use local, and OLTP databases tend to use global indexes, and even how you

can rebuild your global indexes as you're doing partition maintenance avoiding a costly rebuild of THE ENTIRE INDEX, and associated downtime. He also includes a great auditing example.

Chapter 14 covers parallel execution such as parallel dml, ddl, and so on. Here is where a book like Tom's is invaluable, as he comes straight out with his opinions on a weighty topic. He says these features are most relevant to DBAs doing one-off maintenance and data loading operations. That is because even in

datawarehouses, todays environments often have many many users. The parallel features are designed to allow single session jobs to utilize the entire system resources. He explains that Oracle's real sweet spot in this real is parallel

DDL, such as CREATE INDEX, CREATE TABLE AS SELECT, ALTER INDEX REBUILD, ALTER TABLE MOVE, and so on.

Chapter 15, the final chapter covers loading and unloading data. A significant portion of the chapter covers SQL*Loader for completeness, but he goes on to celebrate the wonders of external tables for loading data into Oracle. In particular there is an option in SQL*Loader to generate the CREATE statement for an

external table that does the SAME load! This is great stuff. External tables provide advantages over SQL*Loader in almost every way, except perhaps loading over a network, concurrent user access, and handling LOB data. External tables can use complex where clauses, merge data, do fast code lookups, insert into multiple tables, and finally provide a simpler learning curve.

Conclusions

Yum. If you love Oracle, you'll want to read this book. If you need to know more about Oracle say, for your job, that's another reason you might read this book. Oracle is fascinating technology, and Tom's passion for understanding every last bit of it makes this book both a necessary read, and a very gratifying

one.

View this review on Amazon.com

Security experts will probably tell you it's not a good idea to be a dummy and also in charge of your own firewall. They're probably right, but it's a catchy title. In this article, I'll quickly go over some common firewall rules for iptables under linux.
First things first. If you don't have the right kernel, you're not going to get anywhere. A quick way to find out of all the right pieces are in place is to try to load the iptables kernel module.

$ modprobe iptable_nat

If you get errors you may need to compile various support into your kernel, and of course you may need to compile the iptable_nat module itself. The easiest way is to download the source RPM for your installed distribution, and do 'make menuconfig' with it's default configuration, that way all the things that are currently working with your kernel won't break when you forget to select them. For details see the Linux Firewall using IPTables HOWTO.
Once the module is loaded, start the service:

$ /etc/rc.d/init.d/iptables start

You will also have to have your interfaces up. I did this as follows:

# startup dhcp

/usr/sbin/dhcpd eth0

# bring up twc cable connection to internet

ifup eth1

You'll need to set some rules. Be sure to get your internet interface, and local network interface right on these commands. First to setup masquerade which allows multiple machines behind your firewall to all share your single dynamically assigned IP address from your internet provider:

$ iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

On my firewall, eth1 is the device which talks to the ISP, and gets the IP address we'll use on the internet. The other interface, eth0 is for my local internal network.

Next be sure to enable VPN traffic through the firewall if you have a VPN connection to your office:

iptables -A INPUT -s 10.0.0.0/24 -p 50 -j ACCEPT

iptables -A INPUT -s 10.0.0.0/24 -p 51 -j ACCEPT

iptables -A INPUT -s 10.0.0.0/24 -p udp --dport 500 -j ACCEPT

Lastly enable ip forwarding:

echo 1 > /proc/sys/net/ipv4/ip_forward

Of course you don't really want to be a dummy forever, so you should read up Linux Firewall HOWTO and other linux docs.

Dear intrepid DBAs, as you go about your day-to-day work, and struggle with requests from every direction take heed of some of these tools and tips and it just might give you enough time for a long lunch, or better yet, a trouble free vacation!

1. Tools to Help You

Take a look at some of these tools, and toolkits. I'm sure you will find some useful technology that will help you with your day-to-day needs.

a. Andy Duncan & Jared Still's Perl Toolkit

Andy & Jared put together a phenomenal book in August 2002 called "Perl for Oracle DBAs". All the ins and outs of using Perl with Oracle, are covered. A large part of the book follows the wonderful Perl DBA Toolkit which you can download here: http://www.oreilly.com/catalog/oracleperl/pdbatoolkit/

b. Steve Feurstein's PL/SQL Unit Testing Framework

Steve Feurstein has authored many books on PL/SQL, Oracle's first choice for encapsulating code and application logic in your database. Now you'll have a framework for automated testing of your code.

http://utplsql.sourceforge.net/

c. Use Remote Diagnostic Assistant

The first time I ran into the RDA was at a NYOUG presentation a few years back. I don't recall the presenter, only that what they described seemed to be a tool that I'd always been looking for. I didn't waste anytime downloading it and giving it a try. This is indeed good stuff.

RDA combines a lot of things into one HTML presentation, from an overview of your system, and it's environment, to database layout, parameters, tuning information, wait events, and on and on. It is particularly helpful when you come upon a database for the first time, and need to get a birds eye view of in, all in one snapshot. Also, for systems where you've been called in to diagnose problems, but for which you nevertheless don't have direct access, you can ask for the output of RDA and review that at your leisure.

You can find it on Metalink here.

d. Various Other Tools and Applications

There are lots and lots of other tools and applications out there, and here's a quick rundown of some of my favorites:

Oracle Session Resource Profiler

The Oracle Session Resource Profiler will assist you with understanding what is going on in an Oracle Session.

http://oracledba.ru/orasrp/

Readline Wrapper

The Readline Wrapper is one of the greatest tools I've discovered recently. I read about it on Howard Roger's website some time back. It wraps the underlying readline call to provide history and command completion to programs that don't already have them. SQL*Plus in all the years it has been in use, strangely still has not been brought into the 21st Century. So this tool can help. The 10g version of SQL*Plus may have improved somewhat.

http://utopia.knoware.nl/~hlub/uck/rlwrap/

PHPOraAdmin

Based originally on phpMyAdmin which was a web-based MySQL administration tool, phporaadmin allows you to modify data in your database, create objects and do various administrative tasks.

http://sourceforge.net/projects/phporaadmin/

Ever wanted to compare two schemas for differences? You could write some convoluted SQL to query the data dictionary, perform various UNION, INTERSECT, MINUS, and JOIN operations, and get some answers. Or you can just download a copy of Oracle Schemadiff and let it do the dirty work for you. Last updated at the end of 2002, it probably lacks knowledge of 10g.

schemadiff Homepage: http://sourceforge.net/projects/schemadiff/

Oracle Code Editor

Oracle Code Editor, allows you to view the PL/SQL stored procedures in your database, and provides color editing, and much more.

http://sourceforge.net/projects/orace/

HammerOra

Want to pound on your database server? Take a look at HammerOra. It includes support for 8i, 9i, and 10g, and provides a TPC-C benchmark test. It can run on Windows or Linux.

http://hammerora.sourceforge.net/

Toolkit for Oracle

Here's a developers toolkit which includes PL/SQL debugger, editor with syntax highlighting, and a schema browser.

http://sourceforge.net/projects/tora/

Log4PLSQL

Want to log messages from your PL/SQL code for debugging? Want to make sure a rollback doesn't impede debug messages. This is the package for you. Connor McDonald has a similar tool library called DEBUG.

http://log4plsql.sourceforge.net/

ProDBA

ProDBA is another developer tool written in Java. It provides an editor, and schema browser.

http://sourceforge.net/projects/prodba/

SQLGotcha

SQLGotcha eliminates some of the dirty work of tracking down sid + serial# when you want to trace a session. Also works with 10046 trace events.

http://www.marceljan.nl/oracle/scripts/oracle_script_sqlgotcha.html

O Meter

Want to keep an eye on the I/O your operating system is doing. Take a look at IO Meter. It works on all sorts of operating systems, and processors.

http://www.iometer.org/

OraRep

Izzysoft offers this tool to help generate HTML reports from Oracle. They also have an OraGen tool for creating new databases, and one for HTML formatting Statspack data.

http://www.izzysoft.de/?topic=oracle

2. Oracle Blogs

Although weblogs have been a phenomenon taking the internet by storm for quite a few years now, the fire has recently spread to the Oracle space. The first thing you'll probably do is start visiting these sites, and then bookmarking them, and then checking back every so often to see if your favorites have been updated. But after a while this can be tedius, or worse you can miss new posts on a site that you'd rather not. RSS to the rescue!

RSS stands for Really Simple Syndication and it allows you to "subscribe" to your favorite blogs. Now there are desktop applications that provide RSS readers(http://www.feedburner.com), and there are even browsers (http://www.flock.com/) which are starting to incorporate it. Personally I prefer web-based sites such as the google homepage, http://www.netvibes.com, or http://bloglines.com/ These sites will even work on your mobile phone!

Ask Tom, though not strictly a weblog, is nonetheless an excellent forum to turn to for ongoing Q&A about Oracle technology, and how it all works.

http://asktom.oracle.com/

David Aldridge's Oracle Sponge weblog provides all sorts of interesting discussions, from new features, to odd quirks, and everything inbetween. Expect good technical content, and thorough discussion.

http://oraclesponge.blogspot.com/

Pete Finnigans site discusses all things related to Oracle security. It also features a very good weblog for day-to-day discussion and updates.

http://www.petefinnigan.com/weblog/entries/index.html

Mark Rittman is another Oracle luminary who I would recommend paying attention to. His weblog discusses Business Intelligence, Reporting, and Data Warehousing with Oracle.

http://www.rittman.net/

Niall Litchfield's Oracle weblog mixes plenty of heavy technical Oracle posts, with the occaisional lighter side postings as well.

http://www.niall.litchfield.dial.pipex.com/

There are many, many more blogs on topics relating to Oracle. Brian Duffs Orablogs site aggregates all of those blogs, and you can get an RSS feed from him, for a really interesting and up-to-date mix of what is happening with Oracle technology.

http://www.orablogs.com/orablogs/

Also, Oracle Technology Network now has a blogs homepage which is really worth checking out as well.

http://blogs.oracle.com/

3. Oracle Discussion Groups

Howard Rogers' has a forums section with various discussions on Oracle topics. You can find his site at dizwell.com:

http://dizwell.com/main/component/option,com_joomlaboard/Itemid,256/

By far the best email list to watch is the Oracle-L list now hosted on freelists.org Though you will find inane banter, and the occaisional flame war, by far the bulk of discussions are technical, and some of the brightest and best in the Oracle world post and contribute. Highly recommended!!

http://www.freelists.org/webpage/oracle-l

Another great email list is Lazy DBA.

http://www.lazydba.com/

And let's not forget the Usenet groups which have been around forever. These are the two main ones for Oracle.

comp.databases.oracle.server

comp.databases.oracle.misc

4. Federated Search

I'm sure you've all searched the Oracle documentation from time to time, and wondered which version of Oracle contained which feature or option, and wished you had a way to search all the Oracle documents at once. Now you have just such a search with the Oracle Federated Search. Of course with the documentation moving to publicly indexable section of Oracle.com, google will surely soon be an even better option.

http://otn.oracle.com/pls/db102/db102.federated_search

Oracle has two very different technologies, each with it's own strengths and weaknesses that implement high availability solutions. In choosing between the two technologies, it's important to factor in the relevant risks, both small and large, to put the entire picture into perspective.

Two Alternatives

RAC or Real Application Clusters, is essentially an always-on solution. You have multiple instances or servers accessing the same database on shared storage in your network. With existing technology limitations, in practical terms, these different servers must be on the same local network, in the same datacenter.

Oracle's DataGuard technology, formerly called Standby database in previous versions, provides a rolling copy of your production database. The standby database is started in read-only mode, constantly receiving change data, sent over from the production database, keeping it always in sync at all times, and at most only a few minutes behind. Were the production server to fail, that server could take over in less than the time the DNS change or IP swap would take. What's more the standby copy can be at another datacenter, or on another continent!

Software Failure

Before we compare the strengths and weaknesses, let's talk about software risks. In the real-world, you can have operator errors, which means someone made a mistake at the keyboard, or someone decided to drop the wrong table, and realized only later their mistake. None of these solutions protect you from that. You would have to recover either point-in-time, or from an export. You could also encounter bugs in software that could cause a crash (downtime) or corruption (data loss and downtime to repair). There are also potential configuration errors, so the more components you have the more potential problems. And then lastly there is the risk of buying into technologies for which experienced help is hard to find.

Hardware Failure

You could have hardware failure of your server, motherboard, memory, nic card, or related problems. You could also have failure of a powersupply in the disk subsystem, failure of one of those boards, or of the fibre channel switch or IP switch. Hence redundancy in these areas is crucial as well. But you can also have power failure on that floor or in the datacenter as a whole, or someone could trip the chord.

Larger Failures

Also in a very real sense, the power grid is at some risk. If the Northeast is any indication, a 24 hours of outage every 20-30 years is not unusual. Beyond power, their is the potential for fires earthquakes, and other natural disasters.

Strengths and Weaknesses

For RAC, it's strength is it's always-on aspect. The second instance is always available, so in as much as hardware failure at the server level goes, it protects you very well.

In terms of weaknesses, however, anything outside the server, disk subsystem, power grid failure, or natural disaster that impacts the hosting facility, it does not protect you against. Furthermore there are more software components in the mix, so more software that will have bugs, and hurdles you can stumble over. Lastly, it may be harder to find resources who have experience with RAC, as it certainly is a bigger can of worms to administer.

For DataGuard, it's strength is that the failover server can be physically remote, even on another continent. This really brings peace of mind, as everything is physically separate. It will survive any failure in the primary system.

In terms of weaknesses, however, there is a slight lag, depending on network latency, amount of change data being generated, and how in-sync you keep the two systems.

Conclusions

In 10g, Oracle really brings to the table world-class High Availability solutions. Both DataGuard and RAC have their strengths and weaknesses. Some sites even use both. Each makes sense in particular circumstances but more often than not, DataGuard will prove to be a robust solution for most enterprises.

Back in 2000 I recall searching for Open Source projects to cover in the book I wrote Oracle and Open Source. My co-author and I found seven web-based applications, a few with Perl and Tcl, four Java tools, and five GTK applications. A search for the keyword "Oracle" on freshmeat a popular Open Source project indexing page, now yields an incredible 184 projects. Granted some may be libraries, or supporting components, but its a heck of a lot of activity.

This story is really about tinkerers, folks that like to play with technologies, and offer up their creations to everyone. Some

end up with serious projects on their hands, and a large following. When Oracle ported to Linux, it was a moment for the tinkerers to get busy.

We've managed to contact the authors of six Oracle Open Source projects, and ask them a few questions about their projects, and how they got started. The authors include:

Ljubomir Buturovic, author of gqlplus

Itzchak Rehberg, author of OraRep

Jeff Horwitz, author of extproc_perl

Paul Vallee, the author of m2o.pl

Tim Strehle, author of the OracleEditor

Clausen Yngve, author of ora2html

In 1998 Oracle released it's Enterprise database for Linux. Truth be told, there were a few of us out there trying to get Oracle 7 SCO binaries working under a Linux emulator and had some success. Nevertheless rumors were running around on the Oracle DBA email lists that inside Oracle, porting had already been finished, and it was just a matter of time. So October of 1998 was an exciting moment, for it meant that tinkerers could start really getting their hands dirty with Oracle. And that they did. Around that time I started an Open Source project called Karma solely to monitor Oracle databases. It got some attention but further, drew me into Open Source development, where before I had just been an enthusiast who utilized the tools and applications everyday. Then in 2000 I started to collaborate on a book for O'Reilly entitled Oracle and Open Source. This was released in April 2001, and brought my attention to the growing world of Open Source applications and tools for Oracle.

With that introduction, here are the six questions we asked each of the authors.

1. Some people got their start with Open Source at a University, doing development with gcc, or using other GNU tools, and naturally gravited to Linux when the project began. When did you first get involved with open source software, and what were your first experiences?

2. When did you first decide to start your own open source project and what motivated you most?

3. In your own words, what does you application, tool or library do? What are it's primary or outstanding features?

4. How did you get involved with Oracle? Were you using the Oracle database before Oracle ported to Linux? As a developer or DBA?

5. Where do you see your development efforts with Oracle moving in the future? What would you like to see happen to your project?

6. What might you like to see Oracle doing more of to encourage development of Open Source applications?

Ljubomir Buturovic, author of gqlplus answers the six questions as follows:

1. I first started using Emacs and gcc in 1992, doing research at Boston University. Later on, as a UNIX developer in 1995, a colleague told me about a free UNIX variant you could run on your own home computer. That's how I got involved with Linux.

2. I wrote this tool (gqlplus) because I needed it to improve my work productivity. Then I decided I should release it for two reasons:

- it is a relatively simple utility which would not be too difficult to maintain

- a couple of colleagues told me that they like it and that other Oracle users may benefit from it

3. In a word, gqlplus is sqlplus with command-line editing, name completion and command history. As most Oracle users know, sqlplus is somewhat inconvenient when it comes to repeating past commands, correcting typing mistakes, issuing slightly different queries etc. gqlplus alleviates this problem by incorporating SQL command editing similar to UNIX shell (bash/tcsh). In addition, it also has table-name and column-name completion, so you don't have to remember long or cryptic names. And it's a drop-in replacement for sqlplus, meaning (almost) everything works exactly the same as sqlplus, except that there is the new added functionality.

4. I've been using Oracle on various UNIX system since 1996 as a developer. I have only recently - 2004 - tried running Oracle on Linux.

5. I would like to see Oracle incorporate this functionality in sqlplus, which would make my project obsolete Not that I don't want to maintain it, but there are some functions which can only be supported by changing sqlplus internally, so that's what I would prefer Oracle to do.

6. I would suggest continue improving support for a wider range of Linux distributions, for example Fedora. Right now Oracle installation on Fedora is decidedly non-trivial exercise which may discourage some potential users

Itzchak Rehberg, author of OraRep had this to say:

1/2. That is already about 10 years ago, and I was running OS/2 at that time. I missed some little utilities, so I decided to write them on my own. Since I was using the script language Rexx for this, these utilities became Open Source as a side effect.

After having started developing my own tools this way, I found Open Source very useful: I could take ideas and even routines from other projects easily without any "permission" or license problems. I was using other Open Source programs, and this way could give back something to the community. So I decided to take the GPL for all of my developments, as far as possible.

Meanwhile I switched to Linux some years ago, and mainly develop in PHP. I ran and run multiple projects for different purposes, all of them are using the GPL. A list of programs/scripts and more details on them you can find at:

- http://www.qumran.org/homes/izzy/ (my private and personal site)

- http://www.izzysoft.de/?topic=software (my business site)

3. Since I had to answer this question for more than one or two applications, please refer to the links quoted for question 1.

4. I was working for a company about 5 years ago, mainly as a developer for PHP based web applications. Since the company was running not only MySQL (I was already used to), but also Oracle databases, I got involved into that. First by writing PHP applications that accessed Oracle databases, together with the problem setting up PHP accordingly. Later on, I became the Oracle DBA for the company by running through the Oracle certification program (becoming an OCP DBA). That was after Oracle was ported to Linux: While the production databases where running under Solaris 8, some of our test databases have been set up under Linux.

5. Not easy to answer globally. For me personally, I would like to see an easier integration of Oracle into PHP, e.g. by providing an appropriate module that would be easy to plug in. At the moment, it is quite tricky to set it up, and you can't do that easily with an RPM paket or the like but rather have to re-compile everything from the scratch. If the PHP setup for the Oracle connections would be as easy as copy a few files and add a line to the php.ini (i.e. setting up an extension), I would provide Oracle support to more of my applications, which right now only support MySQL and PostgreSQL, which belong to the "shipped" PHP contributions.

6. See above. PHP got quite common for web development. Oracle databases are quite common in commercial environments. To bring both together, and encourage developers to support Oracle databases with their PHP/database driven applications, an easy integration of Oracle into PHP would help a lot!

These answers are from Jeff Horwitz, author of extproc_perl.

1. That's exactly where I got started. I was a student programmer at the University of Michigan when I was first exposed to open source software. At first I was limited to just downloading, porting, and compiling various packages, but in time I began writing my own software. In 1997 I wrote my first open source package, Authen::Krb4, which provides a Perl API to Kerberos 4.

2. Each project is different, but I assume you want to talk about extproc_perl, which is the only Oracle project on my plate. As a system administrator, I work very closely with our DBA. Knowing my experience with Perl, he commented to me one day, "Gee Jeff, wouldn't it be nice if I could use regular expressions in my select statement?" Now, this was back in 2001, long before 10g's regular expression support. I took that as a personal challenge, and that night, extproc_perl was born.

3. extproc_perl embeds a Perl interpeter in an Oracle external procedure, allowing you to write stored procedures in Perl. Among other things, it supports per-session interpreter persistence, the ability to query/update the database within the existing transaction, and automatic type conversion between Oracle and Perl. The most intriguing feature though, is the ability to leverage the vast number of modules in CPAN (the official Perl module archive) for your stored procedures.

4. I've been a system administrator at a university and two companies that all happened to use Oracle. I think the first time I actually developed anything for it was back in 1997, well before the Linux port. But I'm still just a sysadmin, and I rely on my friendly DBA for most database tasks. For someone who has done what I've done with Oracle, I know surprisingly little about it!

5. As I'm involved with several open source projects, my involvement on each of them, including extproc_perl, tends to ebb and flow like the tides. Development stalled on extproc_perl in mid-2004 as I began work on a new project, but I expect to get back into the swing of things for another release in 2005.

6. Get the word out. Publicize projects that use Oracle in an open source environment. Most people are simply not aware of the quality open source projects that are available to them, and rely on vendors like Oracle to tell them how to do X, Y, and Z. That's all well and good for what Oracle does best, but as we like to say in the Perl world, there's more than one way to do it.

We interview Paul Vallee, the author of m2o.pl, and here's what he had to say.

1. Well, at Pythian we've been running Oracle on Linux for our customers since around 1999, so our experience with open source software started primarily as a beneficiary. We really love the cost savings and flexibility it provides, not to mention the dramatic pace of feature improvements all along the stack.

2. When we first wrote m2o.pl, it was in support of a single migration and interfacing project for a client. Our contract with the client had us owning the intellectual property we built, and yet we had no anticipated use for the software once the project was over. What a waste! So we decided to open-source it because we felt that that would allow the work to be reused in other shops.

3. Well, m2o.pl is a very simple tool that does a very simple thing: it takes mysql create syntax and parses it, then outputs it back into Oracle-compatible create syntax.

4. I first worked with Oracle when it was Oracle 5 on... believe it or not... PC-DOS! I was a developer tasked with a statistical macrosimulation analysis of defense human resources data and we had Oracle 5 and SAS to choose from. I'm embarassed now to admit that for this purpose, SAS beat out Oracle handily. However, since then I've continuously worked with Oracle primarily as a DBA and DBA manager. In 1997, I co-founded Pythian Remote DBA and to this day our primary support focus is the Oracle database.

5. Honestly, I am amazed at how much interest the project receives and how many hits I get on our website directly related to m2o. However, if there's one bone of contention or disappointment is the ratio of feature quibbles to patches I get - Most of the feedback I receive sounds a lot more like "your software didn't handle this correctly" and not a lot like "here's a patch that fixes this Oracle 10 issue for you". I believe that the average user of open-source software has become less and less willing to contribute back over the years.

6. Oracle could open-source their legacyware. For instance, Oracle advanced replication has been completely rewritten since the Oracle 7 days when it was delivered in wrapped PL/SQL. However - that replication totally worked! No doubt their new replication is better - so why haven't they open-sourced the Oracle 7 PL/SQL yet? We could be riffing off that and building fancy new things overlaid on top of it. Replication is just one example of software Oracle has shelved instead of releasing. It would be trivial to come up with more.

The following answers are from Tim Strehle, author of the OracleEditor tool.

1. Back in university, and during my first day job, I got in touch with some commercial Unix flavors - coming from Windows (where I developed Microsoft Access applications), this was a scary world.

So I knew there would be a lot to learn when I started working for Digital Collections. Their first programs had been developed on NeXT computers; later they moved to a client/server model with Unix servers and Mac and Windows clients, all software being written in C. But at the time I joined them, their next major software release was to be a web application written in PHP, running on Unix, Apache and Oracle.

The only thing I knew about PHP 3 was its website, and simply from browsing the online manual, you could tell that PHP would be a good choice for developing web applications. Even at that time it supported so many databases, had lots of useful-looking extensions - and the best online language and function reference I had seen so far.

I was able to learn PHP incredibly fast, and while the PHP manual contributed to that success, it helped even more that my boss, Thies C. Arntzen, was one of the core PHP developers and an Apache Software Foundation member. He taught me the foundations and the tricks of the language, and it was fascinating to see how a PHP feature request or bug discussed with Thies resulted in a solution implemented in the next official PHP release. I really appreciate the privilege of having learned PHP directly from a PHP genius. It has been a great introduction into the world of open source software...

2. Like probably most software developers, from time to time there's a need to build a tool for in-house use. We wouldn't mind giving these tools away for free, but usually they aren't polished or generic enough to be useful for others.

In early 2003, while building a new in-house tool, I decided to take the time to make it useful for people outside our company as well. While I was curious to find out what kind of feedback I would receive, my main motiviation was that I wanted to give something back: I'm making a living building (closed source) software on open source projects like Linux, Apache and PHP, so it felt right to contribute some free software myself.

3. My company's (commercial, closed source) software was running on Oracle on Solaris, HPUX, Irix and AIX; I was developing on Oracle 8 on Solaris. The advent of Oracle on Linux was very exciting for us, it made it so much easier to run Oracle on relatively cheap hardware.

4. I hope that my OracleEditor.php script will continue to attract new users, and perhaps new co-developers - and I love getting suggestions for improvement.

Oracle has proven to be a solid foundation to build upon, so there's a promising future for Oracle-based tools like mine.

5. For years, you felt like a niche developer when building PHP software on Oracle. This feeling has really changed with the advent of Oracle's Open Source Developer Center, the JDeveloper 10g PHP Extension and the announcement that PHP would be included in Oracle Application Server 10G. That's been very encouraging, and all I wish for is that the Open Source Developer Center stays alive and keeps getting frequent updates. Good work!

6. I'm looking forward to seeing what you're making out of these interviews.

The following answers are from Clausen Yngve, author of ora2html.

1. The first time I laid my hands on anything open source, was around '96, when I attended a course in OS Design at the University of Tromso (In Norway). To provide us with a safe environment for programming (safe as in not ruining things for other people , we were provided with laptops running Red Hat linux. The transition from using win* products was eased somewhat by the fact that the univeristy was running UX terminals, and I had been using them for regular work and programming for about a year in advance. But I'm not going to claim the switch was without failures I was slightly tempted to convert my home-PC to Linux or BSD at the time, but it just seemed a little bit too advanced for me. And I couldn't play Doom and Quake running Linux

At the time I didn't really give much thought to what was open source or not - and I guess I didn't _really_ start using Linux/GNU/Open Source software seriously until '98 when I started working as a unix sysadmin. From there on I've been using open source software on a regular basis.

2. In early 2002 it started to dawn on me that there were a lot of things I didn't know about configuration, features and possibilities in the oracle database - and I didn't have a clue where in the database to look for information about all the stuff I didn't know about At the same time, I faced the challenge of keeping track of a growing number of databases in my company. Keeping manual track of a handful of databases isn't too bad, but after looking up version and options information for 50 databases, you sort of loose interest

I eventually decided to create an automated routine for extraction of general database information to help me in my daily work. Inspired by the cfg2html project (Where a few of my friends were involved), I decided to share my utility just in case somebody else would find it useful.

3. My utlity is a small-ish shell script that collects information about configuration and setup of oracle software and databases installed on a server. It logs on to the available databases and runs checks on different aspects of database operation, including memory config, storage utilization, security, installed options, versions ... and so on. The end result is saved as an html file for easy browsing.

It's mainly a utility geared towards DBAs that want an easy method of getting system information. I've found it to be a useful source of reference information in administrative tasks like capacity planning, database upgrade/migration, space management and security auditing. It could probably be useful in disaster/recovery scenarios also.

I recommend running it from cron with automated transfer of the end result to a web server. That makes the info easily accessible. I've also found the source code to be a good place for cannibalizing parts for other DBA-related scripts

4. I've been working with Oracle since '98 when I started working as a unix sysadm with part-time DBA responsibility. That was on an HP platform. I'm not sure which Oracle version was the first to be ported to linux, but I did try the 8.0 release. I've never done much work on Oracle/Linux combinations, though.

5. My project is really just a small utility that doesn't require much effort to keep updated. These days it's just updated as a result of discovered bugs, or upon requests. There are still 10g features I've omitted from my utility, but until I see a real use for the info, I'll delay it.

6. Hm. I don't think I have any well-founded thoughts on that issue. Yet

Like all databases, MySQL needs a disaster recovery plan. In this article we discuss some specific experiences at a client site where disk errors began to cause database problems, and how the disk was replaced, and the database recovery process.
Introduction

MySQL is a great database, and for this client, 2000 subscribers and an average of 200,000 hits per month, it is more than enough. In our case we are using MyISAM tables, which do not support transactions. What that means is that as soon as you insert, update, or delete data, it is immediately reflected in the database files. Discussions of what context this is relevant and sufficient for your application are beyond the scope of our discussions here.
Discovering the problem

The application first starting showing trouble with errors on the website about sessions. My first thought was the database itself could be down, so I checked for running processes:

$ ps auxw | grep mysql

Seeing that the processes were running, I thought one might be hung, so I stopped and started the database just to be sure. This is a quick process, so wouldn't impact things much. Besides most frontend users were probably experiencing the session problem, since almost every page you view on the site checks your session identifier:

$ /etc/rc.d/init.d/mysql stop

$ /etc/rc.d/init.d/mysql start

The session problem continued to rear it's ugly head, so I looked into table checking. First I ran myisamchk on the sessions table:

$ cd /var/lib/mysql/my_db_name/

$ myisamchk activesessions.MYI

The name of the table in this case is "activesessions" and the name of the database for my example purpose is "my_db_name". Checking on the frontend, the site began to work again, so I thought the problem was solved.
Within fifteen minutes, I'm getting paged by the client again, and realize the problem is not solved, and I'm starting to worry a bit. This is not normal behavior, and I'm worrying about corruption. I shutdown the database, and do a thorough repair of all tables:

$ myisamchk -r -s --update-state *.MYI

I startup the database again, and find that there is still intermittent problems. I'm also starting to check the logfiles. /var/log/mysqld.log and find that the database is crashing, and then being restarted every few seconds. Corruption I wonder? I verify that our backups are intact, then start looking further afield. I check /var/log/messages and find something serious:

Mar 12 01:58:51 www kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

Mar 12 01:58:51 www kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=857785, sector=857712

Mar 12 01:58:51 www kernel: end_request: I/O error, dev 03:01 (hda), sector 857712

Mar 12 01:58:51 www kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }

Mar 12 01:58:51 www kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=857785, sector=857720

Mar 12 01:58:51 www kernel: end_request: I/O error, dev 03:01 (hda), sector 857720

Immediately I call support, and discuss the problem.
Replacing the Disk

Luckily the disk is still working well. That means a "ghost" of the disk can be done to a new disk without errors. If the disk had crashed, it would have been a much more difficult recovery. The support folks go ahead and do the ghost procedure after shutting down the machine completely, which is something roughly akin to:

$ dd if=/dev/hda of=/dev/hdb bs=1024

The unix command "dd" does a device to device copy, and will copy every block without change. The support folks may have a hardware solution which does this.
Repairing the Database

After the machine came back online, I shutdown the database again (it starts automatically at boot).

$ myisamchk -r -s --update-state *.MYI

Once that's done, I startup the database:

$ /etc/rc.d/init.d/mysql start

Problem solved.
Monitoring

Going forward it couldn't hurt to write some scripts for Nagios to watch /var/log/messages for errors. Searching for the string "UncorrectableError" would make sense. In addition, a script to monitor the results of myisamchk would also be a good idea.
Conclusion

MySQL recovered fine from this brush with disaster, but one may not always be so lucky to have the disk repair be so straightforward. That's why the dumps of the database, and regular backups are so important. Be proactive, or learn Murphy's Law the hard way. One way or the other we all run into these issues sooner or later.

Need assistance?  Call Us: +1-212-533-6828

or hullsean at gmail

Migration to MySQL - Limitations, Anomalies, Considerations & Strengths

June 15, 2011 Article: What is a Database Migration?

New Article :: Migrating MySQL to Oracle Guide

New Article :: Oracle to MySQL Migration Considerations

This article was actually written around 2006 timeframe.  Some of the comments regarding missing features in MySQL are no longer valid in 2010.  MySQL 5.1 is very robust and feature rich, matching Oracle in many different areas including datatypes, stored procedures and functions, high availability solutions, ACID compliance and MVCC, hotbackups, cold backups and dumps, full text and other index options, materialized views and much more.  To generalize, Oracle remains ahead in terms of it's cost based optimizer, and complex query optimization, as well as high concurrency, and utilizing large SMP boxes.  It also remains ahead in areas of clustering.  However by far the biggest difference between the two technologies is cultural.  MySQL rooted in the open source tradition is much more do-it-yourself and roll your own, while Oracle provides many named and proven paths to solve specific problems.

INTRODUCTION

MySQL is a powerful database platform for many simple web-based applications. Some of it's power and speed comes from it's simplicity. MySQL is actually a database without proper transactions. What this means in terms of speed is dramatic. However it also means you cannot rollback an update which encounters problems halfway through, and other sessions in the database will immediately see changes. There are many dramatic ramifications of this, as we'll discuss later. Lastly there are limitations on dataset size. Oracle can obviously handle tables of a terabyte and larger. However since MySQL implements a table as one file, filesize limits as well as internal data organization, and indexing can become major limitations as tables grow to the millions of rows and higher.

When you begin to hit these limitations, whether in your application complexity, or the size of your data, you may consider moving your data and application to the Oracle Database. There you will have a rich set of features both on the programming side with stored procedures, views, materialized views, triggers, and so on. You will also have support for tables and indexes of virtually limitless size, full transaction support, and even sophisticated High Availability features such as Advanced Replication, Data Guard, and even clustering with Oracle's Real Application Clusters technology.

With all these enticing features, and robustness, you're eager to jump into Oracle. But don't move so fast. There is a temendous amount of planning involved with both moving your data, and porting and testing your application on the new platform. Add to that Oracle licensing, and you'll need some time to get there.

MySQL vs Oracle - feature comparisons

MySQL is a database fit for some types of applications. These tend to be smaller applications, or those which integrate applications with less sophisticated needs than those running Oracle on the backend.

It makes sense at this point to go through a feature comparison, and see what features MySQL shares with Oracle.

MySQL shares with Oracle good support for database access including ODBC and JDBC drivers, as well as access libraries for Perl, Python and PHP. MySQL and Oracle both support binary large objects, character, numeric, and date datatypes. They both have primary and unique keys, and as of 4.x with InnoDB, MySQL has foreign keys, and transactions including READ UNCOMMITED, READ COMMITED, REPEATABLE READ, and SERIALIZABLE. Both databases have sophisticated language and character set support. MySQL can do table locking, and recently improved to include row-level locking. What's more if you don't need transactions, MyISAM tables are extremely fast. MySQL also includes a good data dump utility which you'll see in action below when we migrate to Oracle. And lastly both databases of course include good b-tree indexes, which no database could be without.

There are, however, quite a number of features we find in Oracle as standard, which remain missing in MySQL. Until recently that included row-level locking, true transactions, and subqueries although as of 4.x those seem to be present. However, those have been present, and core technologies in Oracle for years, with very stable and solid implementation, you're sure to achieve dramatic performance on tpc benchmarks. Views are still absent in MySQL, though they may be around the corner with subqueries available now.

Of course a lot of the high end Oracle features remain completely absent from MySQL, and may never be added. Features such as parallel query, and partitioned tables, which include a whole host of special features such as the ability to take one partition offline without impacting queries on the rest of the table. The indexing on partition tables is sophisticated too, allowing partition elimination, and range scans on indexes of specific partitions. There are other large database features such as special functions for star queries. Oracle has terabyte databases in production, so this fact speaks for itself.

MySQL still has a somewhat limited set of index types. For instance Oracle has reverse key, bitmap, and function based indexes, as well as index organized tables. These are all very powerful features for developers who are trying squeeze that last bit of performance out of complex SQL queries against large tables. Although MySQL does provide some index statistic collection, Oracle provides the full set of statistics, including histograms, and makes great use of it inside the Cost Based Optimizer. These statistics allow Oracle to better determine the best method of getting the data for your query and putting it together for you with the least use of resources in tems of memory cache, and disk access. This is really key for a database. When running large multi-user applications all of which are vying for data in different tables, you want to load just the data you need, and nothing more. Avoiding full table scans by

using the proper index, and using various indexes in a join operation to pull fewer rows from the underlying tables means less disk I/O, which other processes are fighting for, and less use of cache, leaving more for other processes.

MySQL still does not have privilege groups, called ROLES in Oracle.

Oracle can also provide column level

MySQL does not have hotbackups which have been an integral part of Oracle for years. In addition, Oracle's RMAN has become a sophisticated piece of software, and grown to be very stable, providing block level backups so only the data that changed can be included in subsequent backups. This makes nightly backups

smaller overall. It also aids tremendously during recovery, providing a lot of automation, and assistence, during those times when you need it most. MySQL's method is to dump data, and further if you want to guarentee a point in time dump of your data, you have to lock all the tables in the database, potentially slowing down your application tremendously. Lastly MySQL does not have automatic or point in time recovery, a real limitation on heavy use production databases.

MySQL also has some limitations on row sizes. MyISAM tables for instance, can have a maximum 64k of data per row, and InnoDB tables 8k per row. This does not include BLOB and TEXT types.

MySQL does not include database links such as those found in Oracle allowing you to query a table from an external database inside a query in a local database. This can be useful for moving data between databases, and is key to implementing

advanced replication in Oracle.

Lastly, MySQL has had some database size limitations. In 3.22 it could only access 4GB of data, however, as of 3.23 the only limitation has been with your operating system, and the size of files it can handle. On Linux with LFS or RaiserFS, this limitation is effectively eliminated. However, Oracle still has incredibly sophisticated

storage cababilities, allowing virtually unlimited datafiles to be associated with a tablespace, and thus virtually limitless sized tables.

Migration preparation

So you've seen what you can do with Oracle, and management has invested in licensing, and you're now ready to get things setup in your development environment.

Now is the time to really get up to speed with Oracle. This goes for both Database Administration knowledge, as well as developer and programmer knowledge. The latter requires that you know a lot about Oracle's features, in particular those which are relevant to your application. The former requires you understanding DBA roles, managing database files, memory structures, backups, and so on and so forth.

Thomas Kyte's books are really excellent, and highly recommended. Check out "Expert One on One" on Wrox Press, and his newer title, "Effective Oracle by Design" which is on Oracle Press. He also has a website, http://asktom.oracle.com.

Also check out Kevin Loney + Marlene Therault's DBA Handbook on Oracle Press. Of course don't forget to read the Oracle docs, which are quite good. Start with the concepts manual for the version of Oracle you plan to go with.

In planning a migration the first thing you should do is take a look at the number, and types of tables in your database. Do that in MySQL as follows:

SQL> show table status

+------+--------+---------+------------+

| Name | Engine | Version | Row_format |

+------+--------+---------+------------+

| t | InnoDB | 9 | Fixed |

| u | MyISAM | 9 | Fixed |

+------+--------+---------+------------+

2 rows in set (0.05 sec)

This output is truncated, but serves as a useful example. You will see the tables, types, and a lot of other information about the tables you will be moving.

You'll next want to review the datatypes of your various tables. CHAR in MySQL maps to CHAR in Oracle, VARCHAR to VARCHAR2, and the various Large Object types to RAW or BLOB in Oracle. DATE, DATETIME, and TIME map to Oracle's DATE datatype, while TIMESTAMP and YEAR map to NUMBER. Lastly all of the various INT datatypes in MySQL map to NUMBER in Oracle and FLOAT, DOUBLE, REAL, and DECIMAL all map to FLOAT.

To get information about the you can use the 'describe' SQL command much like Oracle's own describe:

mysql> describe t;

+-------+----------+------+-----+---------+----------------+

| Field | Type     | Null | Key | Default | Extra          |

+-------+----------+------+-----+---------+----------------+

| id    | int(11)  |      | PRI | NULL    | auto_increment |

| s     | char(60) | YES  |     | NULL    |                |

+-------+----------+------+-----+---------+----------------+

2 rows in set (0.01 sec)

Another way to get useful descriptions of tables is to use the mysqldump command. Here 'test' is the name of the database, and 't' is the name of the table. Leave the table name off and the output will include all the tables in that database.

$ mysqldump test t

--

-- Table structure for table `t`

--

DROP TABLE IF EXISTS `t`;

CREATE TABLE `t` (

  `id` int(11) NOT NULL auto_increment,

  `s` char(60) default NULL,

  PRIMARY KEY  (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

There's actually quite a bit more output, and depending on the version of MySQL you may see additional comment lines etc. You'll probably want to redirect the output to a file. Do so as follows:

$ mysqldump test t > t_table.mysql

$ mysqldump test > test_db.mysql

You will also want to get a sense of which columns are indexed to be sure that they get indexed in your Oracle database. Here is an example of how to list the indexes on a table:

mysql> show index from t;

+-------+------------+----------+--------------+-------------+

| Table | Non_unique | Key_name | Seq_in_index | Column_name |

+-------+------------+----------+--------------+-------------+

| t     |          0 | PRIMARY  |            1 | id          |

+-------+------------+----------+--------------+-------------+

1 row in set (0.04 sec)

An enumerated datatype is one where you define a static set of values up front. Oracle does not currently have such a datatype. The closest equivalent is a VARCHAR2 of sufficient size to hold all the various types. Migration Workbench will

do just that. If you want Oracle to enforce your set of values add a check constraint on that column.

Lastly, if you're experiencing serious performance problems in MySQL, take a look at the slow query log. MySQL can be configured to dump queries which do not execute within a certain number of seconds, to a log file for your review. You can then use the EXPLAIN facility, a much simplified version of the facility found in Oracle, to tune queries for better execution path, possibly requiring a new index on a certain column or an index rebuild. In many instances restructuring a query can be of substantial

benefit.

What's more many of these skills of tuning and optimizing queries will translate directly to Oracle. Queries are the lifeblood of your application. Bad ones can kill overall database performance by filling the cache with useless blocks of data and pushing out previously cached, and important data. What's more inefficient queries cause more disk I/O which impacts the overall performance of your database. These issues hold true for all databases, and getting proficient with them now will

bring you up to speed faster with Oracle as you migrate.

Moving your data between MySQL and Oracle

At this point we're still presuming that you will be moving your data by hand. This is not because we are gluttons for punishment. It is more to illustrate important points. Doing things by hand goes over each and every detail of the process so you understand it. You'll need to when things go wrong, as they inevitably will. So we're discussing moving the schema, and then the data by hand for all tables, however you may end up following the instructions below for using the Oracle Migration Workbench, and then only doing one or two special tables by hand. Or you may decide to use Migration Workbench to build scripts for you as a starting point, and then agressively edit those for your particular needs. All these options are valid.

So at this point you need to dump data. If you want to load data with Oracle's SQL*Loader, an easy format to start with is CSV or Comma Separated Values file.

To dump one table named 't' from database named 'test' use this bit of code. Note that we've broken things up into multiple lines to easily illustrate what's happening with all those messy SED commands. You're welcome to modify them for your needs but this works as-is. Note that ^V requires you to type ctrl-V and requires you to type ^I ctrl-I. Read your editor manual for details on inserting control characters into a file.

#!/bin/bash

# 1. get all rows from table t of database test

# 2. add double quote at beginning

# 3. replace tabs with ","

# 4. add double quote at end

# 5. remove header line

echo 'select * from t;' | mysql test \

 | sed -e 's/^/\"/' \

 | sed -e 's/^V^I/\"\,\"/' \

 | sed -e 's/$/\"/' \

 | tail -n +2

Now is your chance to really put all those Oracle skills to work. You want to have CREATE TABLE statements to build each table, and scripts are an excellent way to get you going. They also self-document the process.

Here is an example of how to precreate the above very simple table in Oracle. Edit a file called t.sql and include these lines:

create table T (

  id   NUMBER(10,0) primary key,

  s    CHAR(60));

Save the file, and then fire up sqlplus and do:

SQL> @t.sql

Table created.

SQL> desc t;

 Name                                 Null?    Type

 ------------------------------------ -------- -----------------------

 ID                                        NOT NULL NUMBER(10)

 S                                                  CHAR(60)

Now use SQL*Loader to load the CSV data you created earlier. To do that you'll need to create a control file. This tells SQL*Loader exactly what to do. Edit a file t.ctl and put this in the file:

LOAD DATA

REPLACE

INTO TABLE t

FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY "\""

TRAILING NULLCOLS

(id INTEGER EXTERNAL, s CHAR)

Once you're done, save the file, and execute the following:

$ sqlldr your_username control=t.ctl data=t.dat log=t.log bad=t.bad

This should load your data into the table t that you created earlier. Check the log and bad files for details, and errors.

As with the Oracle Migration documentation, and any good documentation really, we'll emphasize and reemphasize the need and importance of testing. You cannot assume that your script does things right, nor can you assume that the script Oracle's Migration Workbench created will do things right. There are an infinite number of anomalies for any dataset, and testing your application is the only way you

can verify you are in good shape.

What's more you also need to verify that your data is correct. Suppose you have a banking application, and you are moving customer data from MySQL to Oracle. Suppose further you have records of monthly deposits and withdrawls against that account. You move the data from MySQL into Oracle, and the web or client based frontend is up and running again, after extensive porting, and testing. Does this guarentee that all the data is correct? Not at all. It means the right fields are in the right places, and probably the datatypes are correct. Imagine that that customer had a very high balance, and when moving to Oracle the field size was too small, and perhaps when the data was loaded, the inserted value failed, or was set to a default value like 0. Obviously you don't want to find out when that customer comes calling. You want to look through the log files when the data is loaded, and then run some verification software against the db to compare values in the old db and the new db, or to calculate checksums such as running through deposits and withdrawls to make sure the current balances check out. This is really the most important step in the process and can't be overstated.

Migration Workbench is Oracle's recommended solution

Oracle's Migration Workbench is a Java-based GUI tool which runs on various Windows versions, and comes complete with wizards to help you perform your migration. The process is divided into three steps.

First you capture your target database. This is done with a series of plugins which support various databases including of course MySQL. One plugin is available to handle 3.22 and 3.23 of MySQL and another one handles 4.x versions of MySQL. Capturing the source database is the same as the process we describe above manually of looking at your tables in mysql, and the columns, and indexes you are using. This is practical and feasible for a small number of tables, however, with hundreds or even thousands of tables, Oracle Migration Workbench becomes more and more of a

necessity.

Second, you migrate the source model to Oracle. This is the process where the Migration Workbench precreates all tables found in the source database, including columns of equivalent datatypes. We describe mappings of MySQL to Oracle datatypes above. Note that Oracle does not have ENUM or an enumerated datatype per se, but it can still migrate this data, and does so to VARCHAR2 in Oracle.

The third and last step is the review the scripts that the Migration Workbench has created, make any changes or modifications and then run them to move your data from your source MySQL database into your new Oracle database.

One thing that is important to remember about a migration is that it will take a lot more time, and end up being a lot more complicated than you expected. I liked this about the documentation. They make it clear from the beginning that planning will be a tremendous help to you in estimating time, and delivering successfully within budget. The documentation is also very thorough in it's coverage of MySQL datatypes, and how they translate to Oracle datatypes, as described earlier in this article. And of course there is a strong emphasis on testing. The Migration Workbench provides customizable scripts which both document actions to be performed and provide a way for you to get your fingers into the works.

Keep in mind while using the Migration Workbench that it is NOT all or nothing. You can use the Migration Workbench, and then edit the scripts to leave certain tables alone, or you can migrate them all, then drop the few you want to do by hand using the methods we describe above. Ultimately a mix of the two will probably serve your needs best, as there is always some amount of manual intervention you want to perform for certain tables.

A migration between two databases is not a trivial undertaking. You have a lot of data, and an application which rely on it all being in the right format, with the right relationships. Moving to a new database, with a larger feature set, slightly different syntax, and different ways of doing things takes time and attention, but in the end you'll be up and running on a sophisticated, scalable, world class database platform.

Oracle has a great set of resources on OTN devoted to migrating to

Oracle. In particular there is the Migration Technology Center

Oracle's Migration Workbench documentation page

MySQL (3.22, 3.23, 4.x) Reference Guide

Introduction

Ever since the announcement of Oracle 9i, Oracle's Real Application Clustering feature has created quite a stir. For those not familiar, 9iRAC is a complete overhaul of Oracle Parallel Server (OPS) from previous versions of the database into a workable product.

For many DBA's, however, this technology is completely out of reach. Without an employer who has already committed to OPS and wants to upgrade, or a client who would like to venture into the unknown, there's no way to get ahold of an en\vironment on which to test it. The lowest entry option for clustering technology has been Fibre Channel. Unfortunately cost is prohibitive.

Enter Oracle's new Linux Firewire project. To some, this announcement is as exciting as Oracle's first announcement of a port of their RDBMS to the Linux platform. Through the release of various Open Source software components, such as a modified ieee1394 driver for sharing external Firewire disks, a clustered filesystem (OCFS), as well as a number of other interesting components, this platform is now within our reach at very low cost.

Part 1 - Introduction

Part 2 - Basic Costs + Hardware Platform Outline

Part 3 - Software Requirements, Versions, etc

Part 4 - Initial Oracle Setup

Part 5 - Firewire + OCFS Setup

Part 6 - Cluster Manager Setup

Part 7 - Cluster Database Setup

Part 8 - Review of Clustered Features + Architecture

Part 9 - A quick 9iRAC example

Part 10 - Summary