While it will work, it's not necessary to move tables to a new filegroup.
If you simply add a file to the databases existing filegroup(s) SQL Server will start using the new file(s).
SQL Server uses a "proportional fill algorithm" when a filegroup has multiple files. So if you add a new file (perhaps on a different volume) to a filegroup, SQL Server ...
Your idea to move tables to a new filegroup should work. It will take those tables offline for the duration of the move, but then they will be available for queries again. You can potentially limit the amount of downtime by doing them strategically, one at a time.
Note if you were on Enterprise Edition, you might be able to utilize the ONLINE index ...
Looks like somebody deleted the log file while it was used by the mongodb process. Deleting log files is such a manner is not a good idea as the process will keep it locked and that means the file will keep occupying space on the disk. Such deleted files entry in the lsof will disappear once the process that is locking it is restarted.
The best way to ...
As you noted, you can do this with tablespaces to split the data over multiple drives. But using tablespaces makes things like restoration and migration more difficult. Also, you have to actually move some objects to this space, or it won't accomplish anything. You set it as the default, but that only applies to new objects, it won't automatically spill ...
Nevermind found it, it's called tablespace now
sudo chown -Rv postgres: /mnt/vdb1/pgdata2;
CREATE TABLESPACE data2 LOCATION '/mnt/vdb1/pgdata2';
SET default_tablespace = data2;
SELECT * FROM pg_tablespace;
My question is about how i can shrink all database files to their minimum size after truncating related tables
To answer your question directly, this is done using DBCC SHRINKFILE command -
DBCC SHRINKFILE (YourDatabaseLogicalFileName,<desired size in MB>)
Here you can read more information on how to use this commnand