Jayanth Katta | Technology, Life, Health & Learning

A Practical Way to Refresh DEV and TEST from PROD Refreshing DEV or TEST databases from PROD is something every DBA does regularly. Traditionally, this meant using RMAN duplicate or Data Pump. Both approaches work, but they take time, consume storage, and often feel heavier than the problem itself. From Oracle 12.2 onwards, a better option exists. Refreshable PDB allows you to clone one PDB into another using a database link and keep it updated using redo. This feature is fully supported in Oracle 19c Standard Edition 2. In this post, I walk through PDB to PDB cloning and refresh, along with the mistakes that usually cost the most time. Why Use Refreshable PDB Refreshable PDB changes how you think about cloning. Instead of rebuilding environments repeatedly, you create once and refresh when needed. It gives you Faster refresh compared to RMAN or Data Pump No export or import cycle Minimal impact on production Ideal for DEV, TEST, QA, and reporting Works even in Oracle 19c Standard ...

Today I ran into one of those issues that looks complex, but turns out to be beautifully simple. Every job I launched in Ansible Automation Platform (Tower / Controller 4.5) just sat there. No output. No errors. No movement. Just PENDING . And sometimes, silence is the loudest signal. What I Saw Everything looked healthy on the surface: Job templates launched successfully Jobs stayed in PENDING forever No logs, no failures, no hints Execution Environments looked perfectly fine At first, I suspected Ansible itself,  playbooks, environments, something deep. But this didn’t feel like a playbook problem. This felt like something wasn’t even starting . The Turning Point When jobs don’t start at all, it’s usually not Ansible… it’s scheduling. So I went one level lower services. That’s when I checked Receptor , the quiet engine behind job execution in AAP 4.x. And there it was: systemctl status receptor ● receptor.service - Receptor    Loaded: loaded (/usr/lib/system...

  There’s a question I often reflect on: Why am I more inclined toward long‑term, consistent investments instead of rushing into real estate or chasing fast returns? I don’t deny the importance of diversification. Any well‑balanced portfolio should ideally be spread across multiple investment types like equities, real estate, fixed income, and alternative assets. But for me, the future‑focused approach offers something deeper than numbers on a balance sheet. It gives me relief, hope, and most importantly teaches me patience. Long‑term investing forces you to trust time rather than timing. Whether it’s contributing steadily to a TTPF, building a 529 plan for education, holding a VUL life insurance policy, or sticking to systematic investment plans, the philosophy remains the same: consistency over intensity. Automating investments, especially in strong, innovative companies like the so‑called Magnificent 7 removes emotion from the equation and replaces it with discipline. These choi...

  Introduction Cloud costs do not always rise because of growth. Sometimes they rise because of configuration. That was exactly the case in our environment. We noticed that Log Analytics costs had climbed to roughly $17,000 per month . At first, nothing obvious stood out. There were no major application changes, no large-scale onboarding of new workloads, and no sudden increase in operational activity. But once we reviewed the ingestion data closely, the real issue became clear: a logging configuration was generating far more data than was actually needed. This post explains what we found, what we changed, and how the environment moved from a high-cost logging model to a much more efficient one while still keeping the right operational and security visibility. The Problem: High Log Analytics Ingestion The first step was to understand which tables were driving ingestion. Using the Usage table in Log Analytics, we reviewed billable ingestion over time and by data type. The results s...

Introduction Backups are one of those things we rarely think about—until the moment we need them the most. In a recent scenario, I had to design a solution to move and retain large SQL Server backups (around 2TB) from on-premises to Azure for a short duration. What initially seemed simple quickly evolved into a design problem involving cost, performance, automation, and reliability . This post walks through the thinking, decisions, and lessons learned. The Problem Multiple SQL Server databases One large database (~2TB) Daily backups required for 2 weeks Fast restore capability needed Cost-sensitive solution This wasn’t just backup—it was controlled, intentional data movement . The Questions That Matter This is where the real engineering begins: Do we need Hot, Cool, or Archive storage? What if restore is needed immediately? Should we copy .bak files or backup directly? How do we automate safely? What happens if authentication expires? How do we handle large databases efficiently? Thes...

  Why do I have adult conversations with Ameya? Why do I tell her how my day went, honestly, not filtered? Why do I share when I felt bad because someone at work wasn’t kind to me? And the bigger question, how would an 18-month-old even understand any of this? Maybe she doesn’t. Not today. But I believe children are always listening. Not just to words, but to tone, to emotion, to how we carry ourselves after life nudges us the wrong way. When I speak to her, I’m not trying to be understood in the moment. I’m trying to build something deeper, an environment where honesty is normal, emotions are not hidden, and recovery is more important than reaction. I want her to see that it’s okay to feel hurt, but also important to let go. That not every bad moment deserves a permanent place in your mind. One day, years from now, maybe she’ll come home from school and say something like, “Dad, my friend was rude to me today. It didn’t feel good, but it’s okay. It’s not important. You are...