Posts Categorized: Pythian
It’s no secret anymore that social networks like Facebook are fast loosing their hyper-active charm. But ask anybody about blogging, and its still there and the future is as solid as rock. Innovation, creation, and quality content with public engagement is what makes it lasting. This Log Buffer acknowledges that fact for the database bloggers.
“You are lucky,” the taxi driver told me when he picked me up at the Ottawa Airport. “It began snowing right after your flight landed.” I personally like snow — just like the Chinese saying, “heavy snow brings heavy harvest”. Yes, I am lucky to be able to work at Pythian where the world’s top…
The new year is here with a bang, and the rythem of everything new is propagating into the database technologies, hence providing database bloggers ample material to write about. This Log Buffer Edition covers all that and more.
The new fresh year is already here amidst fireworks, hard partying, resolutions, and new hopes. Log Buffer also enters into this brand new year focusing on the emerging trends while appreciating the proven technologies. Enjoy the first log buffer of this year.
Yes you can still disable triggers per-session in Oracle 126.96.36.199, but you have to have a GoldenGate license, set the
enable_goldengate_replication parameter, use a program name that starts with
replicat, and set your module to
Jingle bells are all the way towards the happy new year. Whether the database bloggers are basking at white, sandy beaches or warming up indoors in white, snowy mornings, they are gearing up with their blog posts to start the new year with a bang. Log Buffer shares that enthusiasm with them.
Oracle provides since it’s 188.8.131.52 version a way to apply certain patches, to our standby environment first, without compromising the primary database, to allow to let it burn in the Standby for the time you deem appropriate and then apply the patch binaries to the primary BD ORACLE_HOME and these will cascade into our Standby DB. The first…
The question of whether a database has enough redo logs available is quite common. The documentation suggests to use FAST_START_MTTR_TARGET and V$INSTANCE_RECOVERY.OPTIMAL_LOGFILE_SIZE to identify “the optimal” redo log size based on the target recovery time. I’ve never used it and can’t comment if it is a correct/reasonable way or not. The easiest way to identify…
I’ve spent the better part of the day troubleshooting an issue with Oracle’s Auto Service Request (ASR) and wanted to share my results in case if saves someone else some effort.