If you don't include the transaction log, then it's not really log shipping, is it?
Your full backup is restored to that point in time, and that's where it will stay until you either (a) apply a log or (b) apply a differential or another full backup. Yes, the restore does also bring over the transaction log, but only the state of the transaction log at that same point in time. I guess technically you could argue that you shipped the log once, but the point of log shipping is to keep the secondary server up to date more often than the full backups (which are typically very large in comparison to periodic log backups).
So if your intention is to do this backup / restore once a day, and you don't need to keep the copy up to date throughout the day, just do a simple backup and restore, and stop calling it log shipping.
If you want the copy to stay relatively up to date throughout the day, then yes, it will be mandatory to take periodic log backups on the primary server and restore them on the secondary server. Note that you have to weigh what's more important: keeping a copy of the data up to date, or letting users query stale data uninterrupted. If you restore a log to the secondary server every 15 minutes, you have to kick all the read-only users out every 15 minutes, because you need exclusive access to the database in order to restore the log.
You can read more information about log shipping here:
http://msdn.microsoft.com/en-us/library/ms187103(v=sql.90).aspx
Since the secondary in a log-shipping configuration is either READ ONLY
or RESTORING
, you cannot make changes to the database (i.e. create a USER) until a ROLE CHANGE happens (i.e. when you failover from primary to secondary). You can create a LOGIN on the secondary server.
You can use this script - How to transfer logins and passwords between instances of SQL Server to script logins - both SQL and Windows.
If you are using SQL Server 2014, then you can just create a ROLE and then grant that role connect any database
and select all user securables
. This works on readonly databases in logshipping configuration as well.
Note that above is not that elegant if you keep security in mind, but still is an alternative that can be considered.
Best Answer
The quick answer is yes, but only for the user permission on the DB, if you got login and user permission on the server-side, you need to copy these ones to the secondary server to avoid the possible issue in case you do a fail over to the secondary server