Posts Categorized: Pythian
Recently, I was upgrading a database from 184.108.40.206 to the current 220.127.116.11 version. The database was using ASM, but I should notify at the beginning that the configuration is for a Stand-Alone Server and not RAC. Basically, the first things to be done for this procedure are part of the following checklist…
Join Francisco Bordenave from Pythian’s MySQL team for a presentation on replication, old and new.
What if we added a new field in the META.json — let’s call it x_help_wanted — that would contains all the different types of help a module maintainer could require? Positions like maintainer, co-maintainer, coder, translator, documentation, and tester. We could even have a Dist::Zilla plugin to populate that field for us.
This is going to be a short one, but I think the changes to GitStore are cool enough to deserve a little blog-squeal.
I played with Mongo and looked at Mongoose, which are nifty, but holy schmolee are Mongo databases huge. And then I re-discovered DBIx::NoSQL, which was pretty much smack what I wanted. But I needed a way to easily serialize my objects for it. So I dragged in MooseX::Storage to the mix. And then I had fun with helper classes and roles to make the interfacing between the two systems as smooth and slick as a buttered piglet.
With the rapid advancement in the database technologies, the legacy systems are either being upgraded or replaced. Or, in some cases, technologists are finding ways to support them in new ways, showing us the flexible nature of databases and the belief of professionals that the sky is the limit. For this Log Buffer Edition, we go even beyond.
A new trial version of DBD::Oracle has been churned out. This release is mostly about Martin J. Evans going all ninjawesome on minor bug fixes as well as paving the way for an upcoming refactoring/speed boost of ora_verbose. As usual, the new version will be soaked for at least 2 weeks before it will turn into its fit-for-general-consumption v1.46 incarnation. Testers, please give this baby a whirl. The full changelog follows for the curious-minded.
I’ve rewritten this blog post in the series to include other new features in SQL Server 2012 outside of high availability and disaster recovery. Ever since the product has been released, I’ve had a chance to look at features that will address performance challenges and business intelligence requirements.
The Ottawa Oracle User Group (OOUG) was kind enough to invite me to give presentations for a whole morning. The group was ultra engaged and asked a lot of good questions, so my usual 50-minute Big Data presentation ended up taking 100 minutes, and the rest of the content had to be squeezed a bit. I hope everyone had a good time!
So how is the actual “waiting on lock” implemented? How does session B, waiting for a transaction to commit started by session A, knows that the resource is free for use? To find out how it is implemented, I have traced Oracle foreground processes. I tried this on Oracle RDBMS 18.104.22.168 running on Linux. This is a excerpt of system calls being executed during a session waiting for a lock…