| Lesson 3 | SQL Configuration and Monitoring Requirements |
| Objective | What you need to take this course. |
SQL Configuration and Monitoring: Course Requirements
With the prerequisites from the previous lesson behind you, this lesson covers what you actually need in front of you to follow along: the SQL Server 2025 environment itself, and the hardware and software it runs on. None of this requires anything exotic or expensive. A reasonably current laptop or desktop, a free SQL Server edition, and a handful of free tools are enough to work through every lesson in this course.
Operating System and Platform Support
Windows is the primary platform for this course, and the most straightforward path if you have a choice. SQL Server 2025 installs on Windows 10 or later, or Windows Server 2019 or later, including Server Core installations of Server 2019, 2022, and 2025. If you've already got a Windows machine you use for the rest of this series, there's nothing further to decide here; install SQL Server 2025 on it and move on to the next lesson.
Server Core deserves a brief word if you haven't run across it before. It's a minimal installation option for Windows Server that drops the usual desktop interface, leaving administration to the command line and remote tools instead. SQL Server supports it fully, and production environments favor it for the smaller footprint and reduced patching surface, but it's not something you need to seek out for this course specifically; a standard, full desktop installation of Windows is perfectly fine for every lesson here, and simpler to work with while you're still learning the SQL Server side of things.
Linux is also a fully supported, native platform, not a workaround bolted on afterward. SQL Server has run natively on Linux since SQL Server 2017, a point this course's first lesson already covered as part of the platform's broader history. If you'd rather work on Linux, a supported distribution such as a recent Red Hat Enterprise Linux or Ubuntu release will run the Database Engine directly, with its own separate, lighter hardware minimums: roughly 2 cores at 2 GHz and 2 GB of RAM to start, noticeably less than the Windows figures later in this lesson. Installation on Linux is typically done through the distribution's own package manager rather than a graphical setup wizard, which is worth knowing going in if a graphical installer is what you're expecting.
There is no native macOS build of SQL Server, so a Mac is the one platform that needs an extra step rather than a direct install. The two practical options are running SQL Server's Linux container image under Docker Desktop, which gives you a real, fully functional local instance inside a container, or connecting to a remote or cloud instance, such as one hosted on Windows, Linux, or Azure SQL Database, from a Mac using cross-platform client tools. Either way, you're not excluded from this course for working on a Mac; you just reach SQL Server a step removed rather than installing it directly on the machine in front of you.
The container route in particular is worth knowing about even if you're on Windows or Linux, since it's a quick way to spin up a disposable instance for testing something without touching your main installation at all. With Docker installed, pulling and starting an instance is a couple of commands rather than a multi-step wizard, something along the lines of pulling the official SQL Server image and then running a container from it with a port mapped out to your host machine. The instance that comes up behaves like any other SQL Server installation from the outside; SSMS or the VS Code MSSQL extension connects to it the same way they'd connect to a native install, and you can throw the container away and start a fresh one in seconds if you want to reset to a clean state.
Windows users have one more option worth a brief mention: the Windows Subsystem for Linux, or WSL2, lets you run an actual Linux distribution side by side with Windows on the same machine, which in turn lets you run SQL Server's Linux build directly rather than through a container. It's a reasonable middle ground if you want hands-on experience with the Linux installation path this course discusses without setting up a separate physical or virtual machine for it.
Server Core deserves a brief word if you haven't run across it before. It's a minimal installation option for Windows Server that drops the usual desktop interface, leaving administration to the command line and remote tools instead. SQL Server supports it fully, and production environments favor it for the smaller footprint and reduced patching surface, but it's not something you need to seek out for this course specifically; a standard, full desktop installation of Windows is perfectly fine for every lesson here, and simpler to work with while you're still learning the SQL Server side of things.
Linux is also a fully supported, native platform, not a workaround bolted on afterward. SQL Server has run natively on Linux since SQL Server 2017, a point this course's first lesson already covered as part of the platform's broader history. If you'd rather work on Linux, a supported distribution such as a recent Red Hat Enterprise Linux or Ubuntu release will run the Database Engine directly, with its own separate, lighter hardware minimums: roughly 2 cores at 2 GHz and 2 GB of RAM to start, noticeably less than the Windows figures later in this lesson. Installation on Linux is typically done through the distribution's own package manager rather than a graphical setup wizard, which is worth knowing going in if a graphical installer is what you're expecting.
There is no native macOS build of SQL Server, so a Mac is the one platform that needs an extra step rather than a direct install. The two practical options are running SQL Server's Linux container image under Docker Desktop, which gives you a real, fully functional local instance inside a container, or connecting to a remote or cloud instance, such as one hosted on Windows, Linux, or Azure SQL Database, from a Mac using cross-platform client tools. Either way, you're not excluded from this course for working on a Mac; you just reach SQL Server a step removed rather than installing it directly on the machine in front of you.
The container route in particular is worth knowing about even if you're on Windows or Linux, since it's a quick way to spin up a disposable instance for testing something without touching your main installation at all. With Docker installed, pulling and starting an instance is a couple of commands rather than a multi-step wizard, something along the lines of pulling the official SQL Server image and then running a container from it with a port mapped out to your host machine. The instance that comes up behaves like any other SQL Server installation from the outside; SSMS or the VS Code MSSQL extension connects to it the same way they'd connect to a native install, and you can throw the container away and start a fresh one in seconds if you want to reset to a clean state.
Windows users have one more option worth a brief mention: the Windows Subsystem for Linux, or WSL2, lets you run an actual Linux distribution side by side with Windows on the same machine, which in turn lets you run SQL Server's Linux build directly rather than through a container. It's a reasonable middle ground if you want hands-on experience with the Linux installation path this course discusses without setting up a separate physical or virtual machine for it.
Software You'll Need
Set aside the specific versions mentioned in older material; this course is built around SQL Server 2025, and that's the version to install. For learning purposes, two editions cover almost everyone taking this course, and both are free:
The licensing distinction between these free editions is worth being precise about, since it's easy to gloss over. Developer edition, in either its Standard or Enterprise flavor, is licensed only for development, testing, and demonstration; the moment an application or a user outside your own learning and testing depends on it, you've stepped outside what the free license covers, and a paid edition becomes the correct choice. Express carries a similar development-and-small-scale restriction baked into its size and resource caps rather than its license terms directly. Neither limitation affects anything in this course, since everything here is explicitly development and learning work, but it's worth understanding now rather than discovering it later if you ever reuse what you build here for something more permanent.
For actually connecting to and working with the instance, SQL Server Management Studio remains the standard tool on Windows, and it's free. If you're on Linux or macOS, or simply prefer an editor-style workflow, the MSSQL extension for Visual Studio Code covers the same ground and runs on all three platforms. This course's first lesson already noted that Azure Data Studio, which used to fill that cross-platform role, was retired, so the VS Code extension is the current answer for anyone not running SSMS directly. Either tool gives you a query window, an object browser for your databases and tables, and enough of a graphical interface to follow the monitoring lessons later in this course without typing every command from a bare command line.
It's worth installing both if you're on Windows, even though you'll only strictly need one. SSMS leans toward dedicated database administration work, with dialog-driven screens for things like configuring server properties or setting up a maintenance job, which this course spends real time on. The VS Code extension leans toward a lighter, more general-purpose editing experience, useful if you're already living in VS Code for other work in this series and would rather not switch tools constantly. Neither one is wrong for this course; the lessons ahead describe what to click or type without assuming you've committed permanently to either one.
Command-line fans have an option too:
You won't need to track down a separate sample database to practice against. This course builds and uses the
- Developer edition gives you the full feature set of a paid edition, licensed for development and testing rather than production use. SQL Server 2025 actually introduced a second Developer option alongside the original: Standard Developer, mirroring Standard edition's feature set, now sits beside the existing Enterprise Developer, which mirrors Enterprise. Either one is a reasonable choice for working through this course, since neither limits the features you'll need to practice configuration and monitoring, and the license terms simply require that you not run production workloads on it.
- Express edition is the free, entry-level option, capped at a 50 GB database size and more modest hardware use. Starting with SQL Server 2025, Express also absorbed the features that used to require the separate "Express with Advanced Services" variant, so a plain Express install now includes things like full-text search out of the box, and you can upgrade an Express install to a higher edition later if you outgrow it.
The licensing distinction between these free editions is worth being precise about, since it's easy to gloss over. Developer edition, in either its Standard or Enterprise flavor, is licensed only for development, testing, and demonstration; the moment an application or a user outside your own learning and testing depends on it, you've stepped outside what the free license covers, and a paid edition becomes the correct choice. Express carries a similar development-and-small-scale restriction baked into its size and resource caps rather than its license terms directly. Neither limitation affects anything in this course, since everything here is explicitly development and learning work, but it's worth understanding now rather than discovering it later if you ever reuse what you build here for something more permanent.
For actually connecting to and working with the instance, SQL Server Management Studio remains the standard tool on Windows, and it's free. If you're on Linux or macOS, or simply prefer an editor-style workflow, the MSSQL extension for Visual Studio Code covers the same ground and runs on all three platforms. This course's first lesson already noted that Azure Data Studio, which used to fill that cross-platform role, was retired, so the VS Code extension is the current answer for anyone not running SSMS directly. Either tool gives you a query window, an object browser for your databases and tables, and enough of a graphical interface to follow the monitoring lessons later in this course without typing every command from a bare command line.
It's worth installing both if you're on Windows, even though you'll only strictly need one. SSMS leans toward dedicated database administration work, with dialog-driven screens for things like configuring server properties or setting up a maintenance job, which this course spends real time on. The VS Code extension leans toward a lighter, more general-purpose editing experience, useful if you're already living in VS Code for other work in this series and would rather not switch tools constantly. Neither one is wrong for this course; the lessons ahead describe what to click or type without assuming you've committed permanently to either one.
Command-line fans have an option too:
sqlcmd, SQL Server's command-line query tool, ships on every supported platform and runs scripts against an instance without any graphical interface at all. It won't replace SSMS or the VS Code extension for the exploratory work this course involves, but it's genuinely useful for automating a script you've already written and tested, and it comes up again later in this course alongside SQL Server Agent. If you've used a different database platform's own command-line client before, sqlcmd will feel immediately familiar; it's the same basic idea of a connection, a prompt, and a batch terminator, applied to SQL Server specifically.
You won't need to track down a separate sample database to practice against. This course builds and uses the
SalesDB example introduced in the first lesson, and you'll have it running on your own instance early in this course rather than restoring someone else's backup file.
Hardware Requirements
The numbers below are Microsoft's current minimums and recommendations for SQL Server 2025 on Windows:
A couple of details here are easy to miss. The processor must be x64; there's no 32-bit SQL Server 2025, so a very old machine may simply be off the table regardless of how much memory it has. SQL Server also scales to a large number of cores per NUMA node on capable server hardware, but nothing on that scale is required to follow this course; any reasonably current laptop or desktop meeting the minimums above is enough to install the engine, build and query
A virtual machine works just as well as physical hardware for this course, whether that's Hyper-V, built into Windows itself, VMware, or a VM hosted by a cloud provider; SQL Server has no objection to running inside one, and a VM is a convenient way to keep this course's instance isolated from anything else on your machine. If you do go this route, give the VM at least as much memory and disk as the recommended figures above call for; a VM squeezed down to the bare minimum tends to make the monitoring lessons later in this course harder to follow, since you'll be watching performance counters that are already under pressure from the VM's own constraints rather than from anything you're intentionally testing.
Storage type matters more than storage type is often given credit for. SQL Server will run on a traditional spinning hard disk, but an SSD makes a noticeable difference even at this course's modest scale, and it's worth remembering for later lessons that disk performance is itself one of the things you'll learn to monitor. If your data and log files already sit on an SSD by default, as they do on most current laptops, there's nothing further to configure here; it's simply useful context for interpreting disk-related performance counters once this course gets to them.
If your available hardware falls short of even these modest numbers, or you'd simply rather not manage a local installation at all, it's worth knowing that running an instance isn't the only option.
| Component | Minimum | Recommended |
| Processor | x64, 1.4 GHz | 2.0 GHz or faster |
| Memory | 512 MB (Express) / 1 GB (other editions) | 1 GB (Express) / 4 GB or more (other editions), scaled to database size |
| Storage | 6 GB free for Setup | Roughly 1.5 GB for just the Database Engine, up to about 8 GB for all features |
| Display | Super VGA, 800x600 | Higher resolution for comfortable SSMS use |
A couple of details here are easy to miss. The processor must be x64; there's no 32-bit SQL Server 2025, so a very old machine may simply be off the table regardless of how much memory it has. SQL Server also scales to a large number of cores per NUMA node on capable server hardware, but nothing on that scale is required to follow this course; any reasonably current laptop or desktop meeting the minimums above is enough to install the engine, build and query
SalesDB, and work through the monitoring exercises ahead. An internet connection is required for some features and for downloading Setup itself, even if the instance you end up running is entirely local and disconnected afterward.
A virtual machine works just as well as physical hardware for this course, whether that's Hyper-V, built into Windows itself, VMware, or a VM hosted by a cloud provider; SQL Server has no objection to running inside one, and a VM is a convenient way to keep this course's instance isolated from anything else on your machine. If you do go this route, give the VM at least as much memory and disk as the recommended figures above call for; a VM squeezed down to the bare minimum tends to make the monitoring lessons later in this course harder to follow, since you'll be watching performance counters that are already under pressure from the VM's own constraints rather than from anything you're intentionally testing.
Storage type matters more than storage type is often given credit for. SQL Server will run on a traditional spinning hard disk, but an SSD makes a noticeable difference even at this course's modest scale, and it's worth remembering for later lessons that disk performance is itself one of the things you'll learn to monitor. If your data and log files already sit on an SSD by default, as they do on most current laptops, there's nothing further to configure here; it's simply useful context for interpreting disk-related performance counters once this course gets to them.
If your available hardware falls short of even these modest numbers, or you'd simply rather not manage a local installation at all, it's worth knowing that running an instance isn't the only option.
Skipping the Local Install Entirely
Everything above assumes you're installing SQL Server on a machine you control, and that's the most common path for working through this course. It isn't the only one. Azure SQL Database and Azure SQL Managed Instance give you a running SQL Server environment without installing anything locally at all; you connect to it over the network using the same tools, SSMS or the VS Code MSSQL extension, exactly as you would for a local instance. The previous lesson already covered why this matters for certification purposes: DP-300 treats on-premises SQL Server, SQL Server on an Azure virtual machine, and Azure SQL Database and Managed Instance as the same underlying job, and that overlap extends to how you can take this course as well.
The two Azure options aren't quite interchangeable. Azure SQL Database is the more hands-off of the two: Microsoft manages the underlying instance entirely, and you work at the database level without ever seeing a server-level configuration screen at all, which actually makes it a slightly awkward fit for a course about server configuration specifically. Azure SQL Managed Instance sits closer to a genuine SQL Server instance, with far more of the instance-level surface area this course covers still exposed to you, at the cost of being a heavier, more expensive service to run. If you do go the Azure route for this course, Managed Instance is the better match for what you're here to learn, even though Azure SQL Database is the one that comes up more often in general Azure discussion.
A Microsoft Azure free account includes a credit that comfortably covers experimenting with either option for the kind of short-lived, intermittent use this course calls for, though the credit expires after a limited introductory period and ordinary usage charges apply afterward. Check Azure's own pricing and free-account pages directly before committing real money, since both change more often than this course does.
This path trades a one-time installation for an ongoing cost once any free trial or credit runs out, so it isn't automatically the better choice; it's simply worth knowing about if your own hardware can't meet the requirements above, or if you'd rather practice in an environment closer to how a cloud-hosted production database is actually managed. Nothing in this course requires it, and nothing in this course assumes you've chosen it over a local install either; the lessons ahead work the same way regardless of which environment you're pointed at.
The two Azure options aren't quite interchangeable. Azure SQL Database is the more hands-off of the two: Microsoft manages the underlying instance entirely, and you work at the database level without ever seeing a server-level configuration screen at all, which actually makes it a slightly awkward fit for a course about server configuration specifically. Azure SQL Managed Instance sits closer to a genuine SQL Server instance, with far more of the instance-level surface area this course covers still exposed to you, at the cost of being a heavier, more expensive service to run. If you do go the Azure route for this course, Managed Instance is the better match for what you're here to learn, even though Azure SQL Database is the one that comes up more often in general Azure discussion.
A Microsoft Azure free account includes a credit that comfortably covers experimenting with either option for the kind of short-lived, intermittent use this course calls for, though the credit expires after a limited introductory period and ordinary usage charges apply afterward. Check Azure's own pricing and free-account pages directly before committing real money, since both change more often than this course does.
This path trades a one-time installation for an ongoing cost once any free trial or credit runs out, so it isn't automatically the better choice; it's simply worth knowing about if your own hardware can't meet the requirements above, or if you'd rather practice in an environment closer to how a cloud-hosted production database is actually managed. Nothing in this course requires it, and nothing in this course assumes you've chosen it over a local install either; the lessons ahead work the same way regardless of which environment you're pointed at.
What's Ahead
The next lesson walks you through actually getting a SQL Server 2025 instance running in whichever of these environments you've chosen, building the
None of the decisions in this lesson are permanent. If you install locally on Windows now and later want to try the Linux path, or spin up a disposable container to compare behavior, nothing about the rest of this course locks you into whatever you pick today. The goal here was simply to get you to a point where some working instance of SQL Server 2025 is reachable from your own machine, by whatever route made the most sense for the hardware and operating system you actually have. Everything from this point forward assumes that instance exists and that you can connect to it; how you got there matters far less.
SalesDB database you'll use for the rest of this course, so you have something real to practice configuring and monitoring going forward.
None of the decisions in this lesson are permanent. If you install locally on Windows now and later want to try the Linux path, or spin up a disposable container to compare behavior, nothing about the rest of this course locks you into whatever you pick today. The goal here was simply to get you to a point where some working instance of SQL Server 2025 is reachable from your own machine, by whatever route made the most sense for the hardware and operating system you actually have. Everything from this point forward assumes that instance exists and that you can connect to it; how you got there matters far less.