作者：eygle 发布在 eygle.com

SQL> select sum(bytes)/1024/1024/1024/1024 TB from v$datafile;

        TB
----------
1.39508572

相关文章|Related Articles

• HDS Truecopy实现原理及项目的选择
  
• DBA警示录：存储故障的处理应当谨慎
  
• Oracle 10g 之HIGH Water MARK 数据统计
  
• 关于HDS的高端存储设备USPV
  
• NetApp FAS200系列 Fas250到货
  

评论数量(1)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/h2recovery_nobackup.html

Video fragments of my session posted at the end — read on.

I arrived at Omni Mandalay Hotel on Sunday evening with Dan Norris. I was flying through Chicago and it turned out that Dan was on the same flight and only few rows behind me. Small world.

Preparations for the conference were very chaotic on my part and, of course, I didn’t have either of my presentations ready. I was very stressed and getting sick as well — it looked like a complete disaster waiting to happen. I’d like to say that I was feeling like Doug Burns as he often managed to get sick just before a conference. Of course, I worked on my slides for the last few days as well as on the flight and presentation was slowly getting there but boy was I tired!

I quickly said hello to the crowd in the bar on the way to my room and rushed away to do some more damage to my slides. And then I had a brilliant idea — I could still see one of my best mates and do something good about my presentation! I asked Doug if he was interested in the preview (he probably wasn’t interested but he couldn’t say it to me) especially that my session wasn’t on his original agenda. Of course, that would mean that he had to leave a bunch of other good friends and spend some time tete-a-tete. Knowing Doug, this is some of the hardest thing to ask from him but it shows how good of a friend he is! (Plus, everyone thinks that he is anti-social anyway. Shhhh!)

Doug has made my day — while he provided lots of ideas and feedback on few things that I was lucking, he generally approved the idea and confirmed that it wasn’t totally crazy. I guess that was all I needed back then and Doug knew how nervous I was about it. (Thanks mate!)

So I called Sunday a day very early and went to bed before midnight. I really needed some sleep. Woken up by the alarm at 5AM (I woke up few times during the night looking at the clock — making sure I didn’t sleep through) and slides were ready just before lunch. I even managed to do a test run and it took 65 minutes — a wee bit too long for one hour session. But it was good test and I knew I had to be just a bit more concise in few parts.

Mi morning was very productive. Unfortunately, I missed the opening keynote from Tom Kyte. Such a pity! If what Doug wrote is true, Tom was talking about the mistakes we make *because* of our experience and our assumptions. This was exactly one of the points I was making in my Battle Against Any Guess — experience is danger. I wish I could see Tom’s example. Oh well, maybe another time.

I managed to attend half of the Richard Foote’s session on indexes but my mind was far away — with my own slides. Though, I did manage to focus on bitmap indexes part and the myth of bitmap indexes not working well for columns with high cardinality. Very interesting conclusions. I’m still wondering how much overhead updates will do to such bitmap index.

After lunch, it was my turn. I ordered few copies of the latest OakTable book — Expert Oracle Practices: Oracle Database Administration from the Oak Table — that I co-authored with the bunch of other Oakies. I contributed chapter 1 in the book titled just like my presentation — Battle Against Any Guess. The plan was to give a copy away during the presentation and do a draw for another one at the end of the session. I was so nervous that I forgot about it until the end of the session so I just did a draw for two copies. The lucky winners were Lynn-Georgia Tesch and Surendra Anchula. Congratulations! For the rest of you who left the contact details — please stay tuned and we’ll organize few things online.

Now the main topic of this post — my presentation. What’s unusual about this session is that it’s not some technical stuff that I usually do but a more conceptual and motivational talk. Could I pull it off? Well, I think it went fairly well in general even though I did identify few rough places and my lack of English language mastering. Might need to work a little bit more on the flow of the presentation.

We had quite a few good laughs. Later, people in the next hall were asking about it and Dan was making the jokes on the stage so it must have been loud. Anyway, I think nobody fell asleep and I managed to get people thinking about the topic. I received many “thank you” notes yesterday and compliments on a good session so by the end of the day I was more and more pleased. Thanks everyone for attending and especially big thanks to those of you who brought to my attention examples from their own battles. If you have more to discuss — contact me by email (my last name) {at} pythian.com.

Thanks to Marco Gralike for recording some fragments and sharing them. I think he has more to come.

This is the introductory couple minutes. You can definitely notice how nervous I am starting on the stage:

Solving the wrong problem example:

That’s all for now. Stay tuned — more to come.

Interesting technology stack behind ☞ xtractr — a network packet analysis tool - combining Ferret, SQLLite, V8, jQuery, Flot, Sammy and CouchDB. According to the linked article, xtractr uses a CouchDB inspired MapReduce for performing packet analysis. I’d say that if you could use it, PIG would have been nice too.

One of the huge challenges in packet forensics is that packets have incredibly rich information content and they come at many different layers each of which might be interesting on its own. Now, we didn’t want to build crazy SQL joins (I’m personally JOIN-challenged) across 90,000+ Wireshark fields. So we ended up using Map/Reduce very much inspired by CouchDB.

1. A Redis monitor for ZenPack (Open Source Network Monitoring and Systems Management) ☞
2. Just a quick reminder that today there will be an ad-hoc NoSQL & beers meetup at Bag O’Nails at 7pm. ☞ See the place on the map.
3. Found this amazing poster on ☞ DarkGreyIndustries blog and I was wondering if we could try to plot each NoSQL project on it. What do you think?
   

   Credit DarkGreyIndustries blog

Some quotes and comments from ☞ (a quite long) interview with Eliot Horowitz, CTO of 10gen, creators of MongoDB:

I think the first question you have to ask about any database these days is, “What’s the data model?”

The only thing I’d add is: “… and how does that fit my problem?”.

That whole class of problems exists because there’s a very clunky mapping from objects to relational databases. With document databases, that mapping becomes much simpler.

I only partially agree with this. There are some scenarios when mappings seem to be easier with document databases, but for very complex models (read hierarchical, multi-relational) things will remain quite the same — I am saying “quite” because you can still use some short routes, but at the end of the day it will depend also on how you’ll use that data.

I also think […] that the object databases before were actually more closely related to current graph databases than to document databases. The document database is really just taking MySQL, and instead of having a row, you have a document. So I think it’s a much simpler transition and it’s actually much closer to MySQL than a lot of people might think.

I assume that the connection with graph databases is based on the following arguments: the connectivity between objects can be very rich and while all that can be persisted it is not accomplished in a transparent way.

The second part is also worth emphasizing, as it is basically a validation of the schema-less relational database, that FriendFeed and others (see [1] and [2]) are using.

If you look at our road map for this year, there’s no one big feature. I think the only big thing we’re doing right now is getting the auto-sharding to be fully production bulletproof.

I totally agree. That auto-sharding feature has been in alpha for too long.

We are sort of similar to MySQL or PostgreSQL in terms of how you could use us, and people want all the features that they’re used to in MySQL and PostgreSQL. These include things like full-text search, SNMP, and all the assorted add-ons providing special indexing.

Is this the market MongoDB is trying to reach? Is MongoDB trying to become the new MySQL? Definitely interesting.

If there was a feature that would hurt our performance, we would think long and hard about implementing it, and we are definitely more interested in making the basics work than we are in adding more features.

I really appreciate this sort of opinionated approach, even if sometimes you’ll have to tell users a bit more about the tradeoffs.

While I’d probably love having the talent to write such ☞big statements, I’d still prefer to get things right firstly:

Elastic Caching Platforms Are KV Stores On Steroids

[…]

NoSQL Wants To Be Elastic Caching When It Grows Up

[…]

Say “Yes” To Elastic KV Stores In Your Architecture

I confess that I see this whole NoSQL and Elastic caching discussion quite differently, as right now it looks to me that elastic caching is the one missing features (especially persistence) and not the other way around. So maybe, Mike Gaultieri, the author of the above quotes, meant the opposite: elastic caching will become NoSQL when it grows up.

Update: Jeff Darcy (@Obdurodon) ☞ is at it again with a much more detailed comment than I could come up with.

I’m not saying that IMDGs (nb: in memory data grids) aren’t valuable. They can be a very valuable part of an application’s computation or communication model. When it comes to that same application’s storage model, though, IMDGs are irrelevant and shouldn’t be presented as alternatives to various kinds of storage.

作者：eygle 发布在 eygle.com

相关文章|Related Articles

• 恩墨科技拟招聘一名Oracle数据库工程师
  
• 来自Oracle公司的职位机会：Principal Consultant
  
• David.Guo的DBA招聘启示 地点广州
  
• 一个工作机会PDM/DBA/上海
  
• DBA需求旺盛 批量招聘DBA
  

评论数量(4)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/fetion_dba.html