When I run rman target / #mydb nocatalog cmdfile=%commands% msglog=%logfile%, I see connected to target database: OTHERDB (DBID=3786352837, not open).
Help!
suppose your target database SID = HR_VMC, to connect this target database issue the following commands to connect it using RMAN
export ORACLE_SID = HR_VMC
sqlplus
SQL> connect / as sysdba
SQL> select name from v$database;
it shows the HR_VCM
open another terminal and from the comman line issue the following RMAN command
RMAN target /
Setting environment variable ORACLE_DB to the target database helps the cause.
Set ORACLE_SID=mydb
StackOverflow and ServerFault seem to suffer from lack of Oracle expertise. Weak.
Related
I have an existing database for which i was looking to create a new clustered environment. I tried the following steps:
Create a new database instance (OS & DB Server).
Take a backup / snapshot from existing database server for all the databases.
Import the snapshot to the new server.
Configure the cluster - referred to various sites but all giving same solution. Example reference site - https://vexxhost.com/resources/tutorials/how-to-configure-a-galera-cluster-with-mariadb-on-ubuntu-12-04/
Ran the command (sudo galera_new_cluster) on the primary server. (Primary server - no issue starting up). But when we tried starting the secondary server - it actually crashed for some reason.
Unfortunately at this point, dont have the logs stored / backed up with me where it failed. But it seemed like it tried to sync in with the primary server - had some failure with that.
As for additional part of the actions performed above. Both the server with same username / password - created a passwordless ssh connection between both the machines. Also, the method of syncing is set to rsync.
Am i missing something or doing it wrong? Is there a better way available on it?
I have been sent a RMAN backup, which is dual encrypted, wallet and password.
The Oracle version is 11.1.0.7.
I am trying to restore the database on a new server.
I performed the following steps:
Create database with ORACLE_SID THEDB using a minimal init.ora file.
Configure the Wallet by copying the ewallet.p12 and cwallet.sso files to a directory, and then adding the ENCRYPTION_WALLET_LOCATION entry into sqlnet.ora.
The next steps are:
sqlplus / as sysdba
startup nomount
select status from v$encryption_wallet;
STATUS
----------------
OPEN
quit
Then RMAN:
rman target / nocatalog
set decryption identified by 'the_backup_pwd';
restore controlfile from 'THEDB_CF_xxxxx_yyy';
ORA-19913: unable to decrypt backup
Now, the backup was taken using AES256 encryption, but the default encryption for this empty database is AES128.
I cannot issue the CONFIGURE ENCRYPTION ALGORITHM 'AES256' command in RMAN as it fails with "database not mounted".
I am certain the wallet and password are correct, but still this error occurs.
What step is missing?
We found out that this only happened if the RMAN Encyrption password had special characters like '$' etc.
The only workaround was to use a heredoc with the password hardcoded .. not great ...
rman / target << EOF
set decryption 'ThePa$$Word'
run {
..
}
EOF
Even when run interactively and the password was manually key it we still got the ORA-19913: unable to decrypt backup. It is obviously a Oracle RMAN bug.
I think I have tried everything but I can't figure out how to set up an SQL Job that have a T-SQL Step that performs a SELECT on a linked server.
1) I got a Domain user mydomain\SQLJob
2) I got a SQL 2017 server 'JOBSERVER' with the SQL Agent running log on as a domain user mydomain\sv_agent (this cannot be changed). No futher rights should be given to this user either.
3) On the JOBSERVER I created a linked server
EXEC sp_addlinkedserver 'LINKEDSERVER'
4) mydomain\SQLJob is data reader on a database on LINKEDSERVER
5) I am able to do a SELECT * FROM LINKEDSERVER... from JOBSERVER in a regular Query Window.
On JOBSERVER I have tried
ALTER DATABASE MyDatabase SET TRUSTWORTHY ON
And then set the job to execute in MyDatabase
I have also tried
Job Step Properties > Advanced > Run as user > mydomain\SQLJob
I have tried adding mydomain\SQLJob to the linked server on JOBSERVER both with and without Impersonate
Could someone let me know what the correct steps are ?
Thanks
I found another post that stated it could not be done.
What I did instead was changing the T-SQL to a PowerShell script. Here the Run As works just fine.
I am very new to AS400, and I am stuck. I have read documenation but cannot find what I need.
I have an odbc connection to an AS400 server. When I run this command I get an Outfile with everything I need:
CALL QSYS.QCMDEXC('DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(CHHFLE/TEST3)', 0000000061.00000)
Instead of the results going to an outfile I need to receive the results of this command to my script that is connecting through odbc. If I change 'OUTPUT(*OUTFILE)' to 'OUTPUT(*)' I get no results when I try to 'fetchall()'.
Is there any way to get this information through the odbc connection to my script?
EDIT: I am on a linux server, in a python script using pyodbc to connect. I can run sql queries successfully using this connection, but I can't figure out how to get the results of a command to come through as some sort of record set.
I hope I'm interpreting what you're asking correctly. it looks like you're accessing user profile data and dumping it to a file. It looks like you then want to use the contents of that file in a script or something that's running on Windows. If that's the case:
In general, when accessing data in a file from the Windows world, whether through ODBC and VBScript, or .NET, the AS/400 is treated like a database. All files in libraries are exposed via the built-in DB2 database. It's all automatic, and part of the Universal DB2 database.
So, after creating this file, you should have a file named TEST3 in library CHHFLE
You'd create a connection and execute the following SQL statement to read the contents:
Select * From CHHFLE.TEST3
This, of course, assumes that you have proper permissions to access this. You should be able to test this using the iSeries Navigator tool, which includes the ability to run SQL Scripts against the database before doing it in your script.
Added after reading comments above
There's info at this question on connecting to the DB2 from Python. I hope it's helpful.
OUTPUT(*) is not stdout, unfortunately. That means you won't be able to redirect OUTPUT(*) to an ODBC connection. Dumping to a DB2 table via OUTPUT(*OUTFILE) is a good plan. Once that's done, use a standard cursor / fetch loop as though you were working with any other DB2 table.
As per this how-to, I've successfully configured IIS on my XP-SP3 dev box for SQL Server 2008 Express to save ASP.NET session state information. I'm just using SQL Server because otherwise on every recompile, I was losing the session state which was obnoxious (having to re-login). But, I'm facing an annoying issue in that every time I restart SQL there's this error, and sometimes one or two other very similar friends:
The SELECT permission was denied on the object 'ASPStateTempSessions',
database 'tempdb', schema 'dbo'.
To fix the error, I just open Management Studio and edit the User Mapping for the login/dbo I'm using on the ASPState db, and re-add tempdb to that user with all but deny permissions. Apparently, once the right permissions are there, ASP.NET is able to automatically create the tables it uses. It just can't run that CreateTempTables sproc until the right security is there.
THE QUESTION...
Is there a way to not have to re-do this on every restart of the SQL Server?
I don't really care right now about keeping the temp data across restarts, but I would like to not have to go through this manual step just to get my web app working on localhost, which uses session state variables throughout. I suppose one could resort to some kind of stored procedure within SQL Server to accomplish the task for this machine when the service starts, to not have to do it manually. I'd accept such an answer as a quick fix. But, I'm also assuming there's a better recommended configuration or something. Not seeing an answer to this on the how-to guide or elsewhere here on StackOverflow.
Both answers seem valid; but with most things Microsoft, its all in the setup...
First uninstall the ASPState database by using the command:
aspnet_regsql –ssremove –E -S .
Note:
-E is to indicate you want to use integrated security connection.
-S informs what SQL server and SQL instance to use, and the "." (dot) specifies default local instance
Then re-install using the command:
aspnet_regsql –ssadd –sstype p –E -S .
Note:
The sstype has three options, t | p | c ... the first "t", tells the installer to host all stored procedures in the ASPState database, and all data in the tempdb. The second option "p" tells the installer to persist data to the ASPState database. The last option "c" allows you to specify a different 'custom' database to persist the session state data.
If you reinstall using the "-sstype p" you then need only to supply datareader/datawriter to the ASPState database for the user that's making the connection (in most cases, the application pool's identity in IIS).
The added benefit of persisting the data is that session state is retained even after a restart of the service. The only drawback is that you need to ensure the agent cleanup job is pruning old sessions regularly (it does this by default, every minute).
Important:
If you are running a cluster, you must persist session data. You're only option is to use sstype 'p' or 'c'.
Hope this sheds light on the issue!
For the record, I did find a way to do this.
The issue is that the tempdb is recreated from the model db each time the service restarts. The gist of the solution is to create a stored procedure that does the job, and then make that procedure run at startup.
Source code (credit to the link above) is as follows:
use master
go
-- remove an old version
drop proc AddAppTempDBOwner
go
-- the sp
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13) + 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
-- add it to the startup
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Well done for finding the strangest way possible to do this.
The correct answer is as follows:
use master
go
EXEC sp_configure 'Cross DB Ownership Chaining', '1'
go
RECONFIGURE
go
EXEC sp_dboption 'ASPState', 'db chaining', 'true'
go