Eliminating unwanted messages from a sqlplus query executed from command line - database

Basically Im trying to get the output of 'DESC HR.EMPLOYEES' via command line.
I have created a file called 'file.sql'
DESC hr.employees;
exit;
Then I execute this on unix command line:
sqlplus username/password #file.sql
My output looks like this, however I want to eliminate all extra messages and want to see only the relevant query result. Any way this is possible? Basically someway to do a silent login / logoff.
SQL*Plus: Release 12.1.0.1.0 Production on Mon Sep 15 19:04:53 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
ERROR:
ORA-28002: the password will expire within 7 days
Last Successful login time: Mon Sep 15 2014 19:04:06 -04:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Name Null? Type
----------------------------------------- -------- ----------------------------
EMPLOYEE_ID NOT NULL NUMBER(6)
FIRST_NAME VARCHAR2(20)
LAST_NAME NOT NULL VARCHAR2(25)
EMAIL NOT NULL VARCHAR2(25)
PHONE_NUMBER VARCHAR2(20)
HIRE_DATE NOT NULL DATE
JOB_ID NOT NULL VARCHAR2(10)
SALARY NUMBER(8,2)
COMMISSION_PCT NUMBER(2,2)
MANAGER_ID NUMBER(6)
DEPARTMENT_ID NUMBER(4)
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
I used the -s option with sqlplus. and that eliminated most of the unwanted messages. But I still get ERROR: ORA-28002: the password will expire within 7 days

You do clearly need to change the password, but if you have a scenario where you need to be able to run a particular script in the meantime, it is possible to hide that message; but you have to move the credentials into the file. (Supplying them on the command line is insecure anyway). So file.sql would become:
set termout off
connect username/password
set termout on
desc hr.employees;
exit;
And you'd run it as:
sqlplus -s /nolog #file
The /nolog means it won't automatically attempt to connect, and when it does so from within the script the output from the connection command is hidden.
Of course, this would hide any other messages related to the account or database availability which would make understanding a failure hard; and you probably really want to be told about the pending expiry so you can change the password - otherwise you'll come to run this a week later and find the account is actually expired, which isn't something you can fix yourself. (Since your example is from the 15th, your account may already have expired, or had its password reset, of course).
Another minor wrinkle with this is that any SQL commands in your login.sql or glogin.sql will show an SP2-0640 error as they will try to run before you are connected.
Just because something is possible doesn't mean it's a good idea, and the potential issues almost certainly outweigh any advantages. So really, when you see the warning, change the password.

This error message ...
ORA-28002: the password will expire within 7 days
...means what it says. The account's password is set to expire and that user will not be able to login within the next week.
You want to get rid of the message? Simple: change the password.
If that solution is undesirable for any reason (I don't know how you use the account) you will need to persuade the DBA to unexpire it. That is probably less simple.

If you want to get rid off the PASSWORD EXPIRY message, then you can set the PASSWORD_LIFE_TIME limit to unlimited. Follow these steps :
SQL> SELECT PROFILE FROM DBA_USERS WHERE USERNAME='SCOTT'
2 /
PROFILE
------------------------------
DEFAULT
SQL>
SQL> SELECT RESOURCE_NAME,
2 LIMIT
3 FROM DBA_PROFILES
4 WHERE PROFILE ='DEFAULT'
5 AND RESOURCE_NAME='PASSWORD_LIFE_TIME'
6 /
RESOURCE_NAME LIMIT
------------------------------ ------------------------------
PASSWORD_LIFE_TIME 180
For your profile, execute :
alter profile <profile_name> limit password_life_time UNLIMITED;
You shouldn't be getting the message again.

Adding -S flag worked for me.
sqlplus -S username/pass#server #sample.sql

Related

SQL Server 2019 > Agent Job execute > Error 'Culture is not supported'

Within the Job History logs - Error on Step 1 : Culture is not supported. Parameter name: culture 3072 (0x0c00) is an invalid culture identifier.
Prior to this issue, I changed the server (MS SQL Server 2019) Computer name After install of SQL Server 2019 plus database and jobs configured.
Occurs on all invokes of jobs.
Tried full uninstall and reinstall of SQL Server 2019, but issue persists.
No need to change the RegEdit Register Editor.
If you are facing the Error 0xc002f210: Preparation SQL Task 1: Executing the query "Culture is not supported. Parameter name: culture 3072 (0x0c00) is an invalid culture identifier." just set the Regional format to English (United States):
This also works if you are trying to import a flat file to Azure SQL Database
I encountered the same error when attempting to run SQL Server Maintenance Plans using the SQL Server Agent.
My local user had a different locale name to the server locale name of the SQL Server Agent Account.
My fix was to delete the Maintenance Plans created by my local account and re-create the maintenance plans on the server using the SA account.
After a day of evaluation, finally found a solution - with help from similar type of reported issue in SSIS, but not quite the same solution. SSIS Error while deploying package The locale identifier (LCID) is not supported by SQL Server
The job unit is initially invoked by logon account {NT Service\SQLAgent$}, but no issue was found with this logon account.
The actually job steps (maintenance plan in my case), uses an OS user account (Administrator in my case), and its this user account culture that became corrupted via the Computer name change.
To fix the user account :
Find the SID of the user (user assigned to the job step that failed)
CMD(with admin privilege): wmic useraccount where name='{user name}' get sid
using the SID from step 1, now find that user in RegEdit
Register Editor -> HKEY_USERS -> [SID of User] -> Control Panel -> International and change keys "Locale" and "LocaleName", example:
Invalid: Locale = 00000C00
Valid: Locale = 00000409 (using LocalName = en-US)
Restart server
Job will still fail with same error at this point.
Final fix > Job step > maintenance plan needs to be recreated, and then it will use the valid culture.
For some reason SQL Server 2019 hardcodes the user account culture to the maintenance plan when the plan is created, and does not update the culture even if the user account - culture is changed.

SQL1397N - The DB2 service failed to logon

I have IBM Db2 10.5.8 on Win10 - I've been using it for many months.
Today, I start the DB2 Command Line Processor and issue the db2start command and I get this error message: SQL1397N The DB2 service failed to logon.
I google, and find out this explanation of the error. I thought maybe the credentials expired for my db2inst local userid, so I check them, I can login to that account with no issues.
I run db2admin setid db2inst mypass just to be sure - no luck.
Stumped, no idea why it fails to login?! Some kind of post vacation syndrome.
Maybe you have already solved this problem but this link helped me.
Change the password for db2admin in setings-->control panel-->administrative tools-->computer management-->users then reboot your computer.
Also, go to Control Panel\System and Security\Administrative Tools\services and update password for DB2 service (i.e DB2 - DB2COPY1 - DB2-0). It's on "Log On" tab.
Other cause might be that you need to activate your db2 license.
Go to local and users groups (lusrmgr.msc)
On Users browse db2admin click properties and
Uncheck Account is disabled click ok
then run db2start
https://i.stack.imgur.com/ESkI7.png

DBMS_CRYPTO.RANDOMBYTES returns null

This statement returns null instead of 64 random bytes:
select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
What is causing it to return null? Database is Oracle 10.1.0.2.0 running on Windows Server 2003 and I want to use the random bytes as salt for password hashing.
Edit: Here's the output from sqlplus:
Connected to:
Oracle Database 10g Release 10.1.0.2.0 - Production
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
SQL>
Edit2: When switching to Oracle 11 the query works. I have no idea why it doesn't work on Oracle 10 but have decided to not use that old database.
It works perfectly. I have tested it on Oracle 12c.
Update
I have checked My Oracle Support(Metalink), however, did not find anything related to this function returning NULL. Certainly, not a bug.
Anyway, looking deeper into the function and it's usage in the documentation, I came across SQLNET.CRYPTO_SEED
SQLNET.CRYPTO_SEED
Purpose
Use the parameter SQLNET.CRYPTO_SEED to specify the characters used
when generating cryptographic keys. The more random the characters
are, the stronger the keys are. The string should be 10-70 random
characters. This optional parameter is required for when encryption or
checksumming are turned on. Encryption is turned on if the
SQLNET.ENCRYPTION_CLIENT parameter is specified for the client and the
SQLNET.ENCRYPTION_SERVER parameter is specified for the database
server; checksumming is turned on if the SQLNET.CRYPTO_CHECKSUM_CLIENT
parameter is specified for the client and the
SQLNET.CRYPTO_CHECKSUM_SERVER parameter is specified for the database
server.
It might be possible that the parameter is not properly set in your environment. I don't have 10g version(obsolete though) to test.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing option
SQL> select DBMS_CRYPTO.RANDOMBYTES(64) from dual;
DBMS_CRYPTO.RANDOMBYTES(64)
--------------------------------------------------------------------------------
427AECD44D27CDF6CDC8F290D9F8079109BAB8AECD7E687E7ADF8E15825BBDF3D746FBC181059443
965B1425B224CC46E8CD07CC2D02B2E023238E8883520A19
SQL>

Cannot login to 'postgres' database as 'postgres' user

I am unable to login to 'postgres' database as 'postgres' user.
OS : REHL Server release 6.3
Postgresql version: 8.4
There is a Database 'jiradb' which is used as a Backend for JIRA 6.0.8.
When I give the command
[root ~]#psql postgres postgres
Password for user postgres: *******
psql: FATAL: could not open relation with OID 2696
How do I fix this error and login to 'postgres' database. Please ask me if you need more details. I am new to postgres DB.
Thanks.
Your postgres database is damaged. oid 2696 is a system reserved oid, so it's a system table, and their oids are stable across databases and across versions. Looking it up on my 9.4, it's:
regress=> select relname from pg_class where oid = 2696;
relname
----------------------------------
pg_statistic_relid_att_inh_index
(1 row)
regress=> \d pg_statistic_relid_att_inh_index
Index "pg_catalog.pg_statistic_relid_att_inh_index"
Column | Type | Definition
------------+----------+------------
starelid | oid | starelid
staattnum | smallint | staattnum
stainherit | boolean | stainherit
unique, btree, for table "pg_catalog.pg_statistic"
so you have a missing file in the data directory for the index pg_statistic_relid_att_inh_index on the system table pg_catalog.pg_statistic.
This should not happen. You have at lest limited data corruption in your datadir.
Your first action should be to stop the database and make a full filesystem-level copy of the entire data directory, per PostgreSQL wiki - corruption.
Then check for possible causes. Recent disk issues? Unexpected/sudden shutdowns followed by fsck, possibly on a system with a non-crashsafe file system, unsafe mount options (e.g. ext3/ext4 data=writeback), unsafe configurations like ext[34]-on-LVM-on-md with barriers on older kernels, etc. Also make sure you're on the latest 8.4 point release.
Only once you have made a full file system level copy of the data directory to safe read-only storage, start the database back up (but not the applications that use it) and see if you can connect to jiradb e.g. psql jiradb. If you can, promptly perform a pg_dump of jiradb and any other databases with data of value.
Do not keep on using the damaged data directory. Now is a good time to do a dump and reload - do a pg_dumpall --globals-only, a pg_dump -Fc of each database, then move the datadir aside, re-initdb, and start back up with a clean install. You might even want to upgrade to a less ancient PostgreSQL at the same time.
Note that it is generally possible to fix issues like this in-place. In this case, if your damaged database wasn't the unimportant-and-usually-empty postgres database, you could start PostgreSQL up in single-user mode with system indexes disabled, then REINDEX the damaged index.

How to resolve ORA-011033: ORACLE initialization or shutdown in progress

When trying to connect to an ORACLE user via TOAD (Quest Software) or any other means (Oracle Enterprise Manager) I get this error:
ORA-011033: ORACLE initialization or shutdown in progress
After some googling, I found the advice to do the following, and it worked:
SQL> startup mount
ORACLE Instance started
SQL> recover database
Media recovery complete
SQL> alter database open;
Database altered
Here is my solution to this issue:
SQL> Startup mount
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> shutdown abort
ORACLE instance shut down.
SQL>
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> Show parameter control_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string C:\APP\USER\ORADATA\ORACLEDB\C
ONTROL01.CTL, C:\APP\USER\FAST
_RECOVERY_AREA\ORACLEDB\CONTRO
L02.CTL
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT'
2
SQL> select a.member,a.group#,b.status from v$logfile a ,v$log b where a.group#=
b.group# and b.status='CURRENT';
MEMBER
--------------------------------------------------------------------------------
GROUP# STATUS
---------- ----------------
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
3 CURRENT
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1904054272 bytes
Fixed Size 2404024 bytes
Variable Size 570425672 bytes
Database Buffers 1325400064 bytes
Redo Buffers 5824512 bytes
Database mounted.
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 4234808 generated at 01/21/2014 18:31:05 needed for thread 1
ORA-00289: suggestion :
C:\APP\USER\FAST_RECOVERY_AREA\ORACLEDB\ARCHIVELOG\2014_01_22\O1_MF_1_108_%U_.AR
C
ORA-00280: change 4234808 for thread 1 is in sequence #108
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
C:\APP\USER\ORADATA\ORACLEDB\REDO03.LOG
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
And it worked:
I had a similar problem when I had installed the 12c database as per Oracle's tutorial . The instruction instructs reader to create a PLUGGABLE DATABASE (pdb).
The problem
sqlplus hr/hr#pdborcl would result in ORACLE initialization or shutdown in progress.
The solution
Login as SYSDBA to the dabase :
sqlplus SYS/Oracle_1#pdborcl AS SYSDBA
Alter database:
alter pluggable database pdborcl open read write;
Login again:
sqlplus hr/hr#pdborcl
That worked for me
Some documentation here
This error can also occur in the normal situation when a database is starting or stopping. Normally on startup you can wait until the startup completes, then connect as usual. If the error persists, the service (on a Windows box) may be started without the database being started. This may be due to startup issues, or because the service is not configured to automatically start the database. In this case you will have to connect as sysdba and physically start the database using the "startup" command.
I used a combination of the answers from rohancragg, Mukul Goel, and NullSoulException from above. However I had an additional error:
ORA-01157: cannot identify/lock data file string - see DBWR trace file
To which I found the answer here: http://nimishgarg.blogspot.com/2014/01/ora-01157-cannot-identifylock-data-file.html
Incase the above post gets deleted I am including the commands here as well.
C:\>sqlplus sys/sys as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Tue Apr 30 19:07:16 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 778387456 bytes
Fixed Size 1384856 bytes
Variable Size 520097384 bytes
Database Buffers 251658240 bytes
Redo Buffers 5246976 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 11 – see DBWR trace file
ORA-01110: data file 16: 'E:\oracle\app\nimish.garg\oradata\orcl\test_ts.dbf'
SQL> select NAME from v$datafile where file#=16;
NAME
--------------------------------------------------------------------------------
E:\ORACLE\APP\NIMISH.GARG\ORADATA\ORCL\TEST_TS.DBF
SQL> alter database datafile 16 OFFLINE DROP;
Database altered.
SQL> alter database open;
Database altered.
Thanks everyone you saved my day!
Fissh
The issue can also be due to lack of hard drive space. The installation will succeed but on startup, oracle won't be able to create the required files and will fail with the same above error message.
I hope this will help somebody, I solved the problem like this
There was a problem because the database was not open.
Command startup opens the database.
This you can solve with command alter database open
in some case with alter database open resetlogs
$ sqlplus / sysdba
SQL> startup
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 8628936 bytes
Variable Size 624952632 bytes
Database Buffers 436207616 bytes
Redo Buffers 3952640 bytes
Database mounted.
Database opened.
SQL> conn user/pass123
Connected.
I faced the same problem. I restarted the oracle service for that DB instance and the error is gone.
What worked for me is that i hadn't set the local_listener, to see if the local listener is set login to sqlplus / as sysdba, make sure the database is open and run the following command
show parameter local_listener, if the value is empty, then you will have to set the local_listener with the following SQL command ALTER SYSTEM SET LOCAL_LISTENER='<LISTENER_NAME_GOES_HERE>'

Resources