New answers tagged

0

Depending on your archive (WAL) retention policy, maybe. Nightly diffs: Relying solely on your nightly differential, your PITR recovery window would only go as far as last Sunday's full backup. From their docs, "Differential Backup: pgBackRest copies only those database cluster files that have changed since the last full backup". Let's say today it's ...


0

If you have enabled innodb_file_per_table, the only way in Operative System can recover and demand to MySQL the used space is through OPTIMIZE TABLE command, you should run that command for you could see equally the data in both ways through .ibd file and using query.


1

sp_databases doesn't seem to be applies to Azure SQL Database (as per MS Official Documentation) which is the same case for sys.dm_os_volume_stats and sys.master_files. However, you may want try with following query, this basically gives break-down of utilized and available space with all mounted drives that are hosting database related files. SELECT ...


0

Can we move the ldf file to the J drive which is 80% free? Yes. Should you? Probably not. In all other 03 replicas we have only I drive with all MDF/ndf/ldf and Temmpdb files. As mentioned in existing answers. optimally each replica should be simulary configured and capable of working as the primary on failover Comparable systems: For a given ...


0

Fundamentally, you may achieve your scenario either Backup - Restore or Detach - Attach method, before proceeding which method to use, consider following recommendations: General Recommendation: Keeping Tempdb files along with user/system databases is not good practice Keep always .ldf into separate drive other than .MDF and .LDF Your scenario ...


1

In our primary replica the drive space is running low with 10% left. Can we move the ldf file to the J drive which is 80% free? Please note that in all 03 read replicas we do not have a J drive. In theory, you can use different disks. (Unless you are using direct seeding to seed the databases to the secondaries). However, I would prefer to have the ...


9

You can find out the storage size with SELECT typname, typlen FROM pg_type WHERE typname IN ('bool', 'int4'); typname | typlen ---------+-------- bool | 1 int4 | 4 (2 rows) However you need to take alignment into account: SELECT typname, typlen, typalign FROM pg_type WHERE typname IN ('bool', 'int4'); typname | typlen | typalign ---...


3

Yes, it is safe to cancel that operation (but you need to be patient and let it finish rolling back - do not panic and stop the SQL Server service or reboot the server; all that will do is make the rollback start over). While you're waiting, let's address your underlying problem. Outside of a scenario where you manually increase the size to prepare for ...


1

A plain VACUUM will make the free space available for new data (i.e., other TOASTed JSON data). If you really want to give the free space back to the OS, and you cannot afford the exclusive lock, try pg_repack: To perform a full-table repack, pg_repack will: create a log table to record changes made to the original table add a trigger onto the ...


Top 50 recent answers are included