SQL Server Cleanup Using UninstallString When Programs and Features Entry is Missing

Issue

In some environments, SQL Server services may still exist on the server, but the related SQL Server entries are missing from Programs and Features. This can happen due to missing or corrupted registry entries, incomplete uninstallations, or failed patching activities.

To identify the uninstall information from the registry, the following PowerShell script can be used:

Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*, `
HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -like “*SQL Server 2016*” } |
Select-Object DisplayName, UninstallString

Solution

The above script helps retrieve the UninstallString for SQL Server components directly from the registry.

In many cases, the uninstall command may contain:

/I

For uninstallation, this should be replaced with:

/X

Example:

MsiExec.exe /x

This forces the uninstall operation instead of launching the installer in maintenance mode.


Important Remarks

  • This approach should mainly be considered for remote support cases or emergency cleanup situations.
  • There is always a possibility of future issues when manually cleaning up SQL Server components using registry-based uninstall methods.
  • The recommended and safest approach is always to rebuild the server if SQL Server installation metadata or registry entries are heavily corrupted.
  • Use this method only as a last resort and proceed at your own risk.

Summary

When SQL Server entries are missing from Programs and Features, the uninstall details can still be retrieved from the Windows registry using PowerShell. Replacing /I with /X in the uninstall command can help remove orphaned SQL Server components. However, since this method relies on registry-based cleanup, it should only be used cautiously in exceptional scenarios, with server rebuild remaining the preferred long-term solution.

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Azure Databricks Series: Step-by-Step Guide to Creating an Iceberg Table from Azure PostgreSQL

Watch this on You Tube https://www.youtube.com/watch?v=Yo0x4u6jc4M

🔗 If you’d like to learn Azure Databricks step by step, check out the full playlist here:
👉 https://www.youtube.com/playlist?list=PLNj2XeCNjFeosTuxZLjfYvnW4H1hsPH07

🌟 Introduction

In today’s data-driven world, organizations need a scalable, open, and flexible way to manage data across storage and compute platforms. Azure Databricks and Apache Iceberg together offer exactly that!

In this blog, we’ll explore how to connect Azure Databricks to Azure PostgreSQL and create an Apache Iceberg table using a simple, step-by-step approach. This approach helps you modernize your data lake and unlock new possibilities for analytics and machine learning. 🚀

💡 What is Apache Iceberg?

Apache Iceberg is an open table format designed for large-scale, analytic datasets stored in data lakes. It brings data warehouse-like reliability to the data lake by supporting:

  • ACID transactions
  • Schema evolution
  • Partition evolution
  • Time travel queries
  • Hidden partitioning

With Iceberg, you can build a true lakehouse architecture that combines the performance of a warehouse with the flexibility of a data lake.

🧩 Why Connect Azure Databricks with Azure PostgreSQL?

Azure PostgreSQL often stores transactional or operational data. But for large-scale analytics, it’s better to replicate or move that data to Iceberg tables in Azure Databricks. This gives you:

  • Faster query performance
  • 🧠 Seamless integration with Spark and ML workloads
  • 🧱 Data versioning and audit support
  • ☁️ Scalable, cost-efficient storage

⚙️ Prerequisites

Before we begin, ensure you have:

  1. ✅ Access to an Azure Databricks Workspace
  2. ✅ A running Azure PostgreSQL Flexible Server
  3. ✅ Correct JDBC connection details (hostname, port, username, password)
  4. ✅ A Databricks cluster with Iceberg support enabled

🪜 Step-by-Step: Creating an Iceberg Table from Azure PostgreSQL

Let’s go hands-on and build it! 👇


🔹 Step 1: Define Connection Details

In your Databricks notebook, start by specifying the PostgreSQL connection details.

jdbcHostname = "jbpos-sql-vnet.postgres.database.azure.com"
jdbcPort = 5432
jdbcDatabase = "postgres"

jdbcUrl = f"jdbc:postgresql://{jdbcHostname}:{jdbcPort}/{jdbcDatabase}"

connectionProperties = {
  "user": "jvivek2k1",
  "password": "xxxxxxxxx", 
  "driver": "org.postgresql.Driver"
}

Here:

  • jdbcHostname → your PostgreSQL server name
  • jdbcDatabase → the database you want to connect to
  • user and password → your login credentials
  • driver → PostgreSQL JDBC driver class

🔹 Step 2: Read Data from Azure PostgreSQL

Now, let’s pull data from your public.customer table in PostgreSQL into a Spark DataFrame.

df = spark.read.jdbc(
    url=jdbcUrl,
    table='public.customer',
    properties=connectionProperties
)

✅ This reads all rows and columns from your PostgreSQL table into Spark.
You can verify the data with:

display(df)

🔹 Step 3: Write Data to an Iceberg Table

Once the data is in Databricks, we can save it as an Iceberg Table in the Unity Catalog or Hive Metastore.

df.write.format("iceberg") \
  .mode("overwrite") \
  .saveAsTable("finance.default.postgres_customer_iceberg")

🔹 Step 4: Validate the Iceberg Table

After writing, you can run SQL queries in Databricks SQL or the notebook itself to validate the table:

SELECT * FROM finance.default.postgres_customer_iceberg;

🌍 Benefits of Using Iceberg Tables in Azure Databricks

1️⃣ High Performance Queries — Iceberg handles large datasets efficiently with advanced partition pruning and metadata optimization.

2️⃣ Schema Evolution — Add or modify columns without rewriting entire datasets.

3️⃣ Data Time Travel — Query data as it existed at any previous point in time.

4️⃣ Open Source & Interoperable — Works with multiple engines (Spark, Trino, Flink, Snowflake, etc.).

5️⃣ Cost-Effective Storage — Store data in open formats on low-cost cloud storage.


🏗️ Real-World Use Cases

  • Building a Data Lakehouse from operational systems
  • Creating auditable, version-controlled datasets
  • Simplifying ETL pipelines by standardizing on Iceberg tables
  • Enabling ML workloads with consistent and reliable data layers

🧠 Pro Tips

💬 Use Azure Key Vault integration to securely store your PostgreSQL credentials instead of embedding them in code.
⚙️ Use Incremental Loads instead of full overwrite for production pipelines.
📊 Consider using partition columns for large tables to improve query performance.


🎯 Summary

In this blog, we:
✅ Connected Azure Databricks to Azure PostgreSQL
✅ Loaded data from a PostgreSQL table into Databricks
✅ Created an Apache Iceberg table for modern data analytics
✅ Validated the data through SQL queries

By combining Azure Databricks + Apache Iceberg + Azure PostgreSQL, you’re enabling a modern, open, and scalable data lakehouse architecture that’s built for performance and flexibility. 💪

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Azure Databricks Series: The Hidden Way to Optimize Costs – No One Talks About!

Managing costs in Azure Databricks can be a real challenge. Clusters often stay idle, autoscaling isn’t always tuned properly, and over-provisioned resources can quickly blow up your bill 💸. In this blog, I’ll walk you through how you can analyze, monitor, and optimize costs in your own Databricks environment using Power BI and AI-powered recommendations.


Why Focus on Cost Optimization?

Azure Databricks is powerful, but without the right monitoring, it’s easy to:

  • Leave clusters running when not in use 🔄
  • Oversize driver and worker nodes 🖥️
  • Misconfigure autoscaling policies 📈
  • Miss out on spot instances or cluster pools

That’s why cost optimization is a must-have practice for anyone running Databricks in production or development.


What You’ll Learn in This Tutorial

Here’s the simple 3-step process we’ll follow:

1️⃣ Collect Cluster Configuration Data

In my previous videos, I showed how to use Azure Function Apps to export cluster configuration details.

These configurations will form the raw dataset for analysis.

2️⃣ Analyze with Power BI 📊

We’ll load the exported data into Power BI and use a ready-made Power BI template (download link below) to visualize:

  • Cluster usage
  • Node sizes
  • Autoscaling patterns
  • Idle vs active time

This gives you a clear picture of where money is being spent.

3️⃣ AI-Powered Recommendations 🤖

Finally, we’ll feed the Power BI output into an AI agent. The AI will provide actionable recommendations such as:

  • Resize underutilized clusters
  • Enable auto-termination for idle clusters
  • Use job clusters instead of all-purpose clusters
  • Consider spot instances to lower costs

Download the Power BI Template

To make this even easier, I’ve created a Power BI template file (.pbit) that you can use right away. Just download it, connect it with your exported cluster configuration data, and start analyzing your environment.

Pro Tips for Cost Savings

💡 Enable auto-termination for idle clusters
💡 Use job clusters instead of always-on interactive clusters
💡 Configure autoscaling properly
💡 Try spot instances where workloads allow
💡 Regularly monitor usage with Power BI dashboards


Final Thoughts

With the combination of Power BI and AI, cost optimization in Azure Databricks becomes less of a guessing game and more of a data-driven process.

📺 If you prefer a video walkthrough, check out my detailed step-by-step YouTube tutorial here: Azure Databricks Series on YouTube

👉 Don’t forget to like, share, and subscribe to stay updated with more tutorials in this series!

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.