How safe is to use BACKUP LOG WITH TRUNCATE_ONLY As per the title, how much is it safe to use BACKUP LOG db_name WITH TRUNCATE_ONLY in last STEP of any SQL-job execution? Randomly found on google that this Code line can be very harmful in use. But how?

I am using my code as below in one of my SQL-job's last STEP.

BACKUP LOG  my_database with Truncate_Only
DBCC SHRINKFILE (N'my_database_Data')
DBCC SHRINKFILE (N'my_database_Log')


Let me simplify the question with below aspects:


What actually doing this code in the SQL-Job? Does it really help?
Is there anything related performance of the DB-Server?
If I remove first line of code (BACKUP LOG), how it can get effect?
Currently I am not able see SQL-Job history of same SQL-Job, is this the reason that it clears all logs?


This could be opinion based question but still let's discuss if you can share some Ideas on it.
What actually doing this code in the SQL-Job? Does it really help?
  


SQL is backing up the log to nowhere and then trying to shrink the data and log files of your database. All of these are bad ideas. Backing up the log to nowhere means you lose point-in-time recovery of your database because you cannot restore these portions of the log. See this link for more info.


  
  Is there anything related performance of the DB-Server?
  


Constantly shrinking your log and data files can cause performance issues because SQL Server has to regrow these files as needed, which causes waits on your queries that require the additional space.


  
  If I remove first line of code (BACKUP LOG), how it can get effect?
  


Before you can reclaim space in the log, you need to backup the data in the log. Removing this would mean your shrinking wouldn't likely free much space, however, as stated before shrinking the log is a bad idea anyway.


  
  Currently I am not able see SQL-Job history of same SQL-Job, is this the reason that it clears all logs?
  


No, this is unrelated. Most likely your SQL Agent history is limited and you have a high-frequency job filling the job history tables. See this link.