DBA Lounge
At $work we have a need for a little job daemon that would poll jobs and process them. But there is more than one type of job, so the solution that we need will have to be a little more complex. To get to my goal, I decided that I would have a generic Poller class. For each type of job to monitor and run, I will create a different object with parameters to tell it how often to poll, how to poll and what to do with the stuff it poll. Sounds good? Perfect, then let’s go.
These days, to craft basic emails, I go with Email::Simple. For the more heavy stuff with attachements and what-nots, I reach out for Email::MIME. Together, they make a pretty awesome duo. But… (come on, admit it, you knew there was going to be a ‘but’)
I think the results we got so far may surprise you. At lease those doesn’t seems to be the results +Alex Gorbachev and +Kevin Closson expected to see. You can find the first related blog post over here. It will give you the necessary context for further reading. Just to recap: +Kevin Closson says “Orion may give It’s VERY easy to get huge Orion nums but reasonable SLOB” and +Alex Gorbachev “lots of the system IO bound below the CPU level so you should see similar number with Orion or SLOB.” Let see what first testing results revealed.
I am going to continue writing about our ongoing IO testing efforts under this blog I decided to provide the first post here to give readers a bit more context. SLOB is nothing but a ~84MB schema with a table and index created in Oracle database to test LIO (if you set a big db_cache_size) or PIO (if you sent a small db_cache). Well by default there are 128 schemas created with the same data structures.IMHO: This is a very good idea to test the performance by executing the same actions that most of Applications do in a real live, but make it so simple that it is application agnostic.
These are my personal rules that I’ve been following moderating the public forums on LinkedIn. I’ve posted on that topic in the discussion on IOUG Exadata SIG forum. As I’m passing RAC SIG group to the next folks on the board (I’m the RAC SIG president until end of August) I needed to hand over my forum management duties too. I decided that it might be useful to the wider audience so why don’t I just publish this on the blog?
Our flagship tool, Support Track, is steadily migrating over to use DBIx::Class to read and manipulate our databases. This is a very useful tool, for many reasons which many people explain better than I could. One of those reasons is that — thanks to the magic of SQLite — it lets us write unit test scripts, and other quick prototyping code, without needing to set up a heavy database server to run against. However, Support Track is powered by Oracle, not SQLite, and while DBIx::Class abstracts most of the differences out of our code, it can’t completely eliminate them. How do we overcome the syntactic differences?
Anybody with a sensible bone in their body would have written a small script to turn a snippets file into an html file and be done with it. Me, I saw an opportunity to work a little more on my Template::Caribou pet project. Bottom-line: there is now the files snipmate_cheatsheet.pl and snipmate_index.pl in Template::Caribou’s repo. They can be used straight from the repo checkout as follows:
By now, I have a few Dist::Zilla plugins interacting with the distribution’s changelog. Each time, I get the changelog, I parse it into a CPAN::Changes object, do something to it and save it again. It’s actually not even as hard as it sounds, have a look.
Stumbled upon this Dell’s article from 2001, So what do we see 10 years later? Singe device, no fuss, everything pre-configured, Oracle RAC, simplified operations — dream of 2001 finally coming true?
Today I got an email reminder that the Metacpan logos are all in and that the voting booths are open, and will be so until Friday the 30th of March 2012, 23:00:00 UTC.
Recent Comments