SQLServerCentral Article

Unlocking Interoperability: A Guide to Foreign Data Wrappers in PostgreSQL and Aurora PostgreSQL AWS RDS

Unlocking Interoperability: A Guide to Foreign Data Wrappers in PostgreSQL and Aurora PostgreSQL AWS RDS As a database professional, I often encounter scenarios where data is fragmented across various systems. In today's distributed IT landscape, it's not uncommon for critical business information to reside in different databases, perhaps an on-premise PostgreSQL instance for legacy applications, […]

SQLServerCentral Editorial

Life's Little Frustrations

As with others, I've had to deal with death in the family recently. Some other family members are dealing with cancer (a few friends too). Happily none of us has recently been a disaster zone, but that's happened too. So yeah, big, nasty scary stuff happens in life. However, for most of us, most of […]

SQLServerCentral Editorial

Databases and Disasters

I was just reading about how the Philippines are working to update their databases in support of faster and better responses in the case of an emergency. While I do volunteer for some of the local emergency services, I'm right at the bottom of the heap as just a radio operator. I don't have any […]

SQLServerCentral Article

When INCLUDE Columns Quietly Inflate Your Transaction Logs

In this article, I wanted to test a common assumption we DBAs make – that adding INCLUDE columns to indexes is harmless. I created a FULL recovery test database with a realistic wide Orders table containing extra large VARCHAR columns to simulate an ERP workload. I ran updates and measured transaction log backup sizes before and after adding INCLUDE columns to a nonclustered index. The results shocked me. The update without INCLUDE columns generated a 10 MB log backup, while the same update with INCLUDE columns produced over 170 MB – a 17x increase in log volume. I explain why this happens: INCLUDE columns are physically stored in index leaf rows, so updates affecting them write bigger log records. I also clarify that updating key columns generates even more log than INCLUDE updates because it involves row movement (delete + insert), but INCLUDE updates still cost more log than if those columns weren’t indexed at all. The takeaway is clear – INCLUDE columns are powerful, but they silently increase transaction log generation, impacting backup sizes, replication lag, and DR readiness. Always measure their real cost before deploying to production.

SQLServerCentral Article

Cassandra Springboot Integration With Redis

Article Overview In this article we will learn how to integrate a Spring boot application with Apache Cassandra database and Redis cache. This is an extension to one of our previous articles which demonstrates the steps to set up Apache Cassandra and how to integrate is with Springboot, link shared below. https://www.sqlservercentral.com/articles/cassandra-springboot-integration In this tutorial […]

Blogs

Five Ways Redshift Serverless Quietly Eats Your Budget

By

It is Friday, the queries are running, and nobody is watching the bill. That...

A Career of Memories

By

Annabel retired from Redgate Software this week. Across most of my career at Redgate,...

Rethinking Index Maintenance: Why avg_fragmentation_in_percent Is Outdated and What You Should Do Instead

By

As a SQL Server DBA with years of experience tuning production environments, I’ve seen...

Read the latest Blogs

Forums

What is the Cloud?

By Steve Jones - SSC Editor

Comments posted to this topic are about the item What is the Cloud?

Changing the Schema

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Changing the Schema

Index Fragmentation Explained: Page Splits, Logical Reads, and What to Do

By Sanket Parmar

Comments posted to this topic are about the item Index Fragmentation Explained: Page Splits,...

Visit the forum

Question of the Day

Changing the Schema

I set up a few users on my SQL Server 2022 instance.

CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1'
CREATE USER User1 FOR LOGIN User1
GO
CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2'
CREATE USER User2 FOR LOGIN User2
GO
CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3'
CREATE USER User3 FOR LOGIN User3
GO
I then created a schema that one of them owned. Under this schema, I added a table with some data.
CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE Myschema.MyTable(myid INT)
GO
INSERT MySchema.MyTable
(
    myid
)
VALUES
(1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO
I granted rights and verified that User2 could access this table.
GRANT SELECT ON Myschema.MyTable TO User2
GO
SETUSER 'USER2'
GO
SELECT * FROM MySchema.MyTable
GO
This worked. Now, I move this schema to a new user.
ALTER AUTHORIZATION ON SCHEMA::Myschema TO User3;
GO
What happens with this code?
SETUSER 'USER2'
GO
SELECT * FROM MySchema.MyTable
GO

See possible answers