27
No, this is not possible.SQL Server 2017 backups cannot be restored by any earlier version of SQL Server ref
Also, regarding detatching and reattaching per the docs:
After being attached to SQL Server 2017, the database is available
immediately and is automatically upgraded. This prevents the database
from being used with an older version of the ...
11
Lets first get the concept of reader / writer threads out of the way
During a backup, SQL Server creates one reader thread for each volume
that the database files reside on. The reader thread simply reads the
contents of the files. Each time that it reads a portion of the file,
it stores them in a buffer. There are multiple buffers in use, so the
...
10
→ Is it possible to restore read-only DB in the new server?
Yes
An example:
CREATE DATABASE ReadOnlyDB;
GO
ALTER DATABASE ReadOnlyDB SET READ_ONLY;
BACKUP DATABASE ReadOnlyDB TO disk = '\\share\readonly.Bak';
destination server is already having a Read-Write(Online) database by
the same name.
Not entirely sure what you mean by this, but you ...
5
Yoy have a couple of options in your situation:
Turn off applications that can change data in the database
Set the database in single user mode and back it up. Something like this:
ALTER DATABASE [<DBName>] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
BACKUP DATABASE [<DBName>] TO DISK = N'<locationAndFilename>'
Then restore it and ...
5
BACKUP DATABASE successfully processed 19696388 pages in 1945.648
seconds (79.088 MB/sec).
The speed you see here is a result of simple division of the whole backup duration per volume of data processed.
In your case backup duration is 1945.648 s, data volume processed is 19696388 pages * 8Kb / 1024 = 153.878,03125 Mb
The speed = 153.878,03125 Mb / ...
3
You could run a RESTORE HEADERONLY on the backup file to read the contents and get the ServerName column.
For example:
CREATE DATABASE BLABLA
GO
backup database BLABLA
to disk = 'c:\temp\BLABLA.BAK'
RESTORE HEADERONLY FROM DISK = 'c:\temp\BLABLA.BAK'
Result:
With the servername column being the one you want for the backup(s) residing in the backup file....
3
What is the best SQL server backup strategy for large DB with few tables and lots of immutable data?
I think you should look into log shipping once you get it setup your 10 minutes logs can be shipped to the server, so only changes are updated.
Assuming the log shipping destination is also where you want your backups kept, you can do backups there. Other then the initial backup, you can run for years and only ship the logs.
You could take full backups ...
3
I am not fully understanding your situation. There are a couple of things not mentioned in the question or existing answers.
While taking backup data should not be changed in any case.
Why? - Any changes that are made during the backup are captured and included in the backup. So if it takes 2 hours for the backup to complete, all the changes made ...
2
Absolutely, that is an option. Do the full backup, and then log backups. At the receiving end, restore all but the last using NORECOVERY.
Automating regular log backups and then restoring at the other end is what we call "log shipping", and there's a feature to do that using Agent jobs in SQL Server. Might, or might now, be relevant for you depending on ...
1
No need to use an editor to corrupt a backup file. You can use a PowerShell script like the example below to write binary zeros at the beginning of the file to corrupt file header.
$backupFile = New-Object System.IO.FileStream("E:\Backups\AdventureWorks.bak", [System.IO.FileMode]::Open, [System.IO.FileAccess]::Write)
$garbage = New-Object System.Byte[] 100
...
1
You don't need UltrEdit to destroy a backup file.
Actually, this really powerful text editor will allow you to nose around inside a backup file and even save it without rendering the file completely unusable ...
Not that you should, obviously.
Good old Notepad is far more capable of causing this sort of damage.
Just open [a copy of] a Backup file and ...
1
I think there may be some confusion here on the word "Shrinking" - The log file is not ever "Shrunk" by a backup. It can be "truncated" by the log backup, but not shrunk.
When a log is truncated, the segments in the log that are no longer needed for recovery (either because you are in SIMPLE recovery model and a checkpoint has ensured that the data is in ...
1
No need to use another tool, you could just:
./mongo -udbadm admin --port 27100 -p --quiet --eval "rs.status().members.find((m) => m.stateStr === "SECONDARY").name"
to get:
example-1.domain:27200
Note that the find method will return the first element found.
1
Could this be the reason for large log files
Yes, particularly with FULL recovery model and if there is NO frequent LOG backups as the in-active VLFs in LOG file cannot be truncated without backup in full recovery model.
With Simple recovery model LOG backup is not the case, most probably at one point of time there might have been a heavy transaction/...
1
What are the permissions set on the file pg_hba.conf?
Does the postgres user have the ability to read it?
Here is my configuration:
-rw-------. 1 postgres postgres 4334 Apr 4 22:14 ./pg_hba.conf
Only top voted, non community-wiki answers of a minimum length are eligible
