2004-11-11
2,427 reads
2004-11-11
2,427 reads
2004-11-10
1,552 reads
2004-11-09
2,229 reads
Another in our series of things you should avoid at all costs. Seems silly at first, not having a detailed recovery plan for your SQL Server. Perhaps it is, but having dealt with any number of problems over the last few years, Steve Jones has some ideas why a detailed plan may not be the best thing to spend your time on.
2004-11-09
8,071 reads
This is the first article by Steve Jones that examines a programming technique for handling operations that may be too large to run in a single query.
2004-11-05 (first published: 2001-05-09)
19,395 reads
2004-11-05
2,388 reads
2004-11-04
2,073 reads
2004-10-28
1,650 reads
2004-10-27
2,276 reads
2004-10-26
2,144 reads
By HeyMo0sh
In my experience, FinOps success has never been just about tools or dashboards. It...
By HeyMo0sh
As a DevOps person, I know that to make FinOps successful, you need more...
By HeyMo0sh
As someone who works in DevOps, I’m always focused on creating systems that are...
Comments posted to this topic are about the item Restoring On Top II
Comments posted to this topic are about the item SQL Art 2: St Patrick’s...
Comments posted to this topic are about the item Breaking Down Your Work
I have a database, DNRTest, that has a number of tables and other objects in it. The other day, I was trying to mock up a test and ran this code on the same server:
-- run yesterday CREATE DATABASE DNRTest2 GO USE DNRTest2 GO CREATE TABLE NewTable (id INT) GOToday, I realize that I need a copy of DNRTest for another mockup, and I run this:
-- run today USE Master BACKUP DATABASE DNRTest TO DISK = 'dnrtest.bak' GO RESTORE DATABASE DNRTest2 FROM DISK = 'dnrtest.bak' WITH REPLACEWhat happens? See possible answers