One of the disks of our exchange 2013 server just crashed. I can recover the mailboxes of the database it contained, but how or where I do it? In the database list it appears the one that is in the disk not working.
Should I create a new database in another disk? If I should do it, how can i move the mailbox to the new database and then import the pst that I have as backup?
I created a new database and then tried to move the mailbox, but nothing happened.
Thanks
I solved it.
Instead of trying to move the mailbox to another database from the manager website, thing that cannot be done as the previous database is lost, one can do this that works:
Get-Mailbox -Database DB01 | Set-Mailbox -Database DB01-new
and then recover the pst in the moved mailboxes of the new database.
Related
Background: hard-drive died in existing Oracle12cR2 server but I was able to recover all the previous tablespaces from backup, including SYSTEM01.DBF and USERS01.DBF. I created a new Oracle 12cR2 database server, and would like to know if I can recover any of the data in the tablespaces?
Thanks.
if you have oracle running in archive log mode and have a recent backup complete with all archives until the crash: yes you can. After that you can use various methods to move the data to the new database.
My question that remains is: why move it to an other database when you were able to recover the original one? The recovered database is as good as (or even better) than the new one.
On SQL Server 2008R2, we have a SQL login tagged with the sysadmin server role. Anytime a db is created, this login is automatically added as a user to the db. Is there a switch that will prevent this from happening?
EDIT:
Based on the answer below, I am adding more background info to explain why we want to do this.
When we publish to a new database from a Visual Studio SQL project, the publishing engine wants to add a user to the database. The username already exists as a login to the database (in the sysadmin server role -- and not much we can do about that), so the publish fails as the user gets auto-added by SQL server after the 'create database' statement. I was hoping for a switch that would tell SQL Server to not add the user automatically. So it seems we will have to find another solution on the VS side that tells the publishing engine to ignore the SQL DB user.
Assuming you're talking about the sql-server role, I don't think so. TBH if you're contemplating keeping a sys-admin out of a db, then you've got a different problem than the one you think you have...
I have a resolution to this. Download the latest SSDT package from MS and now there are new options under the Publishing Wizard Advanced... button to exclude the publishing of logins, roles, etc. The SSDT package I downloaded I found here...
https://msdn.microsoft.com/en-US/dn864412
I've just started a job and have identified an issue in which the database isn't currently being backed up properly so to speak. We are doing one back up every 6 hours that uses the Oracle native backup utility, but we were also sold a process by a company in which they stated that they could in essence perform "warm" backups of our database by simply taking file system copies of our database files and when we needed to restore we'd simply shut down Oracle and then copy over the files that had been copied, restart Oracle and the world would be whole again. The challenge is the fact that we have not gotten this to work just yet. I need to spend some more time reviewing the message that Oracle is giving, but my primary question is, "Is it possible" to take copies of Oracle files while Oracle is still running and to use those files at a later date to restore the database? I know that it works if the database is shut down, and then copies are made, but this is the first that I've heard that a copy (file system) can be made while the database is running. Any guidance would be greatly appreciated. Here is the error that we are getting.
ORA-00314: log 3 of thread 1, expected sequence# 1939 doesn't match 1944
ORA-00312: online log 3 thread 1: 'E:\ORACLE\ORADATA\ITMS\REDO03.LOG'
Yes, it is possible, but you have to put all the tablespaces into backup mode first and take them out afterwards (e.g. ALTER TABLESPACE x BEGIN BACKUP and ALTER TABLESPACE x END BACKUP; you'll need to check the syntax and make sure it's appropriate for your situation!). Oversimplifying hugely, this tells Oracle not to write to any of the data files, so they're all kept in a consistent state.
The two main problems you get otherwise are that individual files are updated while you're copying them so a single file can be corrupted; and more visibly that different files have different internal timestamps and sequences so Oracle won't allow them to be used.
If you're using a process you've bought in then it should already be taking care of all that though. It sounds the backup is OK and it's the restore that you haven't got working.
I haven't been involved in a restore from a hot backup for some time so someone else will need to give the detail on the actual error. My read of it is that you've tried to open with the restored data files but the later live redo logs. When restoring I think you either have to RECOVER the database using the redo logs generated since the backup was taken; or if you're trying to restore to that point in time then you can open the data with the RESETLOGS directive and lose all the changes from all the redo logs that came later. But really take more informed advice than this...
As far as I know, there are two ways that you can "copy" datafiles from a running Oracle instance.
The datafiles are copied for a
tablespace when the tablespace is in
"BEGIN BACKUP" mode.
You are using a high-end journalling
filesystem such as Veritas that can
snapshot and track block
changes on the filesystem while the
copy is taking place.
It is possible. You must must be in ARCHIVELOG mode.
An example script would be for manual:
Alter tablespace USERS begin backup;
host cp -p /u02/oradata/PROD/users01.dbf /u03/backup/PROD/
host cp -p /u02/oradata/PROD/users02.dbf /u03/backup/PROD/
Alter tablespace USERS end backup;
However, I would recommend just using RMAN. RMAN is QUITE ROBUST, included free, and will do the hot backup, as well as cold. It will clone to another instance, clone as a point in time, recover to a certain point in time, etc. Any manual backup procedure should be migrated to using the RMAN.
If you wanted to backup the entire database while it is open (I prefer as Oracle with DBA so you can avoid passwords in scripts, but ymmv):
$ ORAENV_ASK=NO
$ ORACLE_SID=PROD
$ . oraenv
$ rman target=/
Recovery Manager: Release 10.2.0.4.0 - Production on Thu Oct 28 14:23:29 2010
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PROD (DBID=x)
RMAN> backup as compressed backupset database plus archivelog;
...
Backup Complete.
I've effectively done this with a non-mission-critical database running on Amazon EC2. My backup strategy is to periodically take a snapshot of the EBS volume. To restore a backup, I create a new EBS volume from the snapshot, start up the instance using it, then run RECOVER DATABASE.
This loses any transactions that were in-flight at the time when the snapshot was taken, of course.
I'm currently using Oracle db11g on Red Hat Enterprise Linux 5.0.
I make an incremental level 0 one time a week and incremental level 1 everyday.
I can restore this backup on my new Linux server without any problems because I have all archive logs generated after level 1 backup.
However, if online redo log is not yet filled (I mean that I have some redo info in the online log), how can I use this online log to roll forward to my restored database on the new Linux server?
I don't want to lose the valuable information that is not yet archived.
Best regards,
Sarith
Restore your backed up files.
Copy your current online redo log files (from the "damaged" production instance) to the new server.
RECOVER DATABASE;
This scenario assumes you have total continuity with archived logs and online logs. In doing the recovery, Oracle will apply necessary archived redo, then move to the online redo logs to recover to the point of failure. Important! Don't restore online redo logs from the backup you have! Use the current online logs from your crashed instance.
Finally, don't believe anything you read without practicing it for yourself!
Yes you can use the unarchived logs - if you applying the archive logs via "recover database using backup controlfile", just supply the redo log name instead of the suggested archive log name that the recovery process provides when it comes to that point (i.e. "runs out" of archive logs).
So you mean you duplicate the database to another server using RMAN?
Online redo logs are only used for disaster recovery. For instance : you lose a datafile, restore the datafile from your latest backup, and apply archivelogs and finaly the online redo logs. This makes the restored datafile have the same SCN (System change number) as the controlfile (and other datafiles). Distaster recovery complete.
When you use your backups to duplicate the database on another server you can only roll forward using your archived logs. It does a incomplete recovery by defenition (creates a new controlfile and redologs).
Do a
SQL> Alter system switch logfile
before backup?
But no matter what restore is behind the source database if it stays open. I don't now your business case exactly but DataGuard might be an option for you.
Rob
We have restored an old ms CRM database over a newer version. But when I try and add users which were already existed in newer version I get an error.
If I delete the users from our of active directory and then try to add them to CRM it works fine.
Is it possible that CRM is storing user information in the MSCRM_CONFIG. And can this be removed in a supported way?
Have a look at the SystemUser in the MSCRM_CONFIG table, I think i need to remove the users from this table. but I can't do a delete statement as it's not supported. :)
Did you restore this database using the Deployment Manager tool or simply by doing a SQL Restore? Doing this directly from SQL would cause issues. You'll need to delete the organization in the deployment manager and then delete the database in SQL. Then you should attach the database and recreate the organization from the deployment manager, pointing it to the existing database.
Restoring just the org DB can lead to issues as some user info is stored in the config DB as well. In fact, there are entries in there mapping the user to the org (SystemUserOrganizations), so when you restore the Org DB, this mapping is now out of date.
You would need to either go the Delete/Import route or manually do some unsupported cleansing of the Config DB Tables.