Sql-server – Restore database according to editions

rman is the way to go for backup and recovery for protection against physical corruption. For documentation check Oracle® Database 2 Day DBA 11g Release 2 (11.2) In the current release of SQLDeveloper backup and recovery is integrated in the GUI. For download of SQLDeveloper see Oracle SQL Developer It is a free product, with active development.

In SQLdeveloper in the View menu select DBA to get access to the dba tools like RMAN and DATAPUMP. Very nice tool. Don't forget that the backup files are written by the Oracle database server processes. This means that the backups are written on the database server, not on your client. Also, currently it just generates a backup script. You should run the generated script using RMAN.

An other way to run and configure the backup is by using dbconsole or grid control.

Using datapump is an other way to protect against data loss. Using this enables you to read back the data as it was during the export. Might be usefull for test sets that have to be refreshed with a specific version of the data. Not really usefull if you want to recover production transactions to the last moment before disaster stroke.

This is the difference between logins and users and how they relate to each other:

• Logins - Instance level principals that allow an entity to connect to the SQL Server instance. They do not, by their nature, grant any access to databases on the instance. The exception to this is a login with sysadmin rights can use a database because they are sysadmin, but because of sysadmin level permissions.
• Users - Database level principals that allow an entity to connect to a SQL Server database. Users are associated with logins via SIDs, creating a relationship between the two and allowing a login to connect to the instance and then use the associated user to connect to the database.

What commonly happens with SQL authenticated logins and database users on a restore is that the SIDS will be out of sync, thus breaking the relationship. This relationship must be repaired before you can connect to the database using that login, because in the eyes of SQL Server those principals are no longer connected. You can fix this with the following SQL:

ALTER USER [foo] WITH LOGIN=[foo]

You can use the following query in the context of your database to check for orphans:

select
    dp.name [user_name]
    ,dp.type_desc [user_type]
    ,isnull(sp.name,'Orhphaned!') [login_name]
    ,sp.type_desc [login_type]
from   
    sys.database_principals dp
    left join sys.server_principals sp on (dp.sid = sp.sid)
where
    dp.type in ('S','U','G')
    and dp.principal_id >4
order by sp.name