Ali Shaik's Database Diary

 Introduction SQL Server is a powerful relational database management system (RDBMS) developed by Microsoft. A crucial aspect of managing any database system is ensuring that the right people have the right access to the database. This is where SQL Server logins and users come into play. In this blog, we'll delve into the concepts of SQL Server logins and users, their differences, and how to manage them effectively. SQL Server Logins What are Logins? A login in SQL Server is a security principal that is used to connect to the SQL Server instance. It's essentially the first step in the authentication process, determining who you are. Logins can be created for: Windows Authentication : Uses Windows accounts to authenticate users. It can be a Windows domain account or a local Windows account. SQL Server Authentication : Uses a username and password stored in SQL Server. Creating Logins You can create logins using SQL Server Management Studio (SSMS) or T-SQL commands. Here’s how yo

In the intricate world of SQL Server performance optimization, the quest for identifying and resolving bottlenecks often feels like a detective's pursuit. Shared resources such as CPU, memory, and disk subsystems can all play a role, making it challenging for Database Administrators (DBAs) to pinpoint the root cause accurately. The Quandary of Misdiagnosis A common pitfall is mis-attributing sluggish query performance to a generic need for more CPU power or faster disks, without delving into the specifics of the performance bottleneck. For example, simply adding more CPU capacity might not be the silver bullet if the majority of response time is tied to I/O waits rather than CPU utilization. Dynamic Management Objects (DMOs): The Game Changer Enter Dynamic Management Objects (DMOs), the silent heroes in the realm of SQL Server performance tuning. DMOs offer a more systematic approach to troubleshooting by enabling DBAs to swiftly narrow down their focus. One powerful application is

IO Usage at the Database Level We can build out further on this information and present the data in a more usable format and provide exactly what we need vs. what the developer of the DMV/DMF may have foreseen it used for by writing our own query with it incorporated into it. WITH IO_Per_DB AS (SELECT DB_NAME(database_id) AS Db , CONVERT(DECIMAL(12,2), SUM(num_of_bytes_read + num_of_bytes_written) / 1024 / 1024) AS TotalMb FROM sys.dm_io_virtual_file_stats(NULL, NULL) dmivfs GROUP BY database_id) SELECT Db ,TotalMb ,CAST(TotalMb / SUM(TotalMb) OVER() * 100 AS DECIMAL(5,2)) AS [I/O] FROM IO_Per_DB ORDER BY [I/O] DESC; The above query now displays total MBPs and percentage of IO across entire SQL Server per database. If we need to few this in a more detailed perspective , i.e. from the data file view vs. the database, ensuring we identify prospective high IO areas that could become a bottleneck, we could use the following query: WITH IO_Per_DB_Per_File AS (SELECT DB_NAME(dmivfs.database_

  Crucial for Performance and Responsiveness: Monitoring latches in real-time is essential for maintaining optimal performance and responsiveness in a SQL Server database system. Role of Latches: Latches, being lightweight synchronization primitives, play a pivotal role in safeguarding in-memory structures from concurrent access. Impact of Excessive Latch Contention: Excessive latch contention can lead to queuing and delays, significantly impacting the throughput and responsiveness of the system. Swift Detection of Bottlenecks: Vigilant observation of latch behaviors in real-time allows database administrators to swiftly detect potential bottlenecks. Preventing Severe Performance Issues: Addressing issues before they escalate into severe performance degradation is crucial for maintaining system health. Insights into Dynamic Workloads: Real-time monitoring not only identifies issues promptly but also provides valuable insights into dynamic workloads and interactions within the server. P

Introduction: In SQL Server, computed columns are a powerful feature that allows you to create virtual columns with values calculated on-the-fly based on other columns' data. While computed columns can simplify data retrieval and improve data consistency, they can also pose challenges when it comes to replication. This blog post explores the issues associated with computed columns in SQL Server replication and presents solutions to tackle them. Understanding Computed Columns: A computed column is essentially a virtual column within a table. It does not physically store its data in the table unless explicitly marked as "PERSISTED." Instead, a computed column derives its value based on an expression that can use data from other columns in the same table. Challenges in Replication: Replication in SQL Server involves copying data from one database (the publisher) to one or more destination databases (subscribers). However, when dealing with computed columns, replication can e

Introduction: Replication is a powerful data distribution mechanism, but it's essential to understand how it interacts with your transaction log. While merge and snapshot replication have minimal impact on transaction logs, transactional replication can significantly affect their size. In this blog post, we'll explore how replication influences transaction logs and offer strategies to manage them effectively. Merge Replication and Snapshot Replication: Merge and snapshot replication don't directly impact the size of your transaction log. These replication methods focus on data synchronization and delivery without significant log-related implications. Transactional Replication: Transactional replication, on the other hand, can affect transaction log size. When a database includes one or more transactional publications, the log isn't truncated until all transactions relevant to these publications are delivered to the distribution database. This can result in transaction l