I think I got the soluton, based on the book online:
"
If the database is offline and does not start.
Try to take a tail-log backup. Because no transactions can occur at this
time, using WITH NORECOVERY is optional. If the database is damaged, use
either WITH CONTINUE_AFTER_ERROR or WITH NO_TRUNCATE.
BACKUP LOG database_name TO [WITH { CONTINUE_AFTER_ERROR |
NO_TRUNCATE }
Important:
We recommend that you avoid using NO_TRUNCATE, except when the database is
damaged.
If the database is damaged, for example, if the database does not start, a
tail-log backup succeeds only if the log files are undamaged, the database
is in a state that supports tail-log backups, and the database does not
contain any bulk-logged changes.
"
I did the following test that proves it works:
1. after restore from a baseline full backup, we have id=200004
1> use testdata
2> select max(id) from big_table;
3> go
Changed database context to 'testdata'.
-----------
2000004
2. insert
1> insert into big_table values(2000006, 1,1, 'x','y');
2> go
(1 rows affected)
1> exit
3. take the database testdata offline
4. delete the data file: c:\Microsoft SQL server\...\testdata.mdf
5. bring the database testdata online ( In SSMS it appears offline though)
6. backup the tail-log with no truncate option
1> BACKUP LOG testdata TO LOCAL_DISK_TESTDATA WITH NO_TRUNCATE ;
2> go
Processed 4 pages for database 'testdata', file 'testdata_log' on file 16.
BACKUP LOG successfully processed 4 pages in 0.106 seconds (0.230 MB/sec).
7. Restore the db ( select the full backup same as in step 1 and the log
backup created in 6)
8. verify
1> use testdata
2> select max(id) from big_table;
3> go
Changed database context to 'testdata'.
-----------
2000006
(1 rows affected)
So the key is to be able to backup tail-log before restore. Now I have some
confidence on SQL Server :-)