记录远程调用Oracle出现的异常:ORA-12514、ORA-01034、ORA-27101

文章讲述了作者在虚拟机上安装Oracle时遇到连接问题,经过排查发现是由于本地监听器设置错误导致。解决方法包括修改listener.ora和tnsnames.ora文件,以及使用sqlplus启动数据库。最终成功解决连接问题并能通过DBEaver登录。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

起因是这样的:我是在虚拟机上安装的Oracle,然后每次通过本机的dbeaver去连,刚开始连的时候没问题,过了两天之后,就出现了:

Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

监听器监听不到服务,我以为是监听器的问题,就去看 C:\oracle\product\10.2.0\db_1\NETWORK\ADMIN 目录下的 listener.ora 文件

将里面的host配置成虚拟机计算机名,或者IP地址也行

结果还是报ORA-12514这样的错,后来我就在虚拟机上登录登录Oracle,发现居然登不上去,一直让我输入用户名和密码,然后还报这样的错:ORA-01034: ORACLE not available ORA-27101:shared memory realm does not exist

原来问题在这里,而不是ORA-12514

解决办法:

打开 C:\oracle\product\10.2.0\admin\orcl\pfile 目录下的 init.ora.816202319487 文件

找到local_listener,如果没有,就自己加

打开 C:\oracle\product\10.2.0\db_1\NETWORK\ADMIN 目录下的 tnsnames.ora 文件,找到红框这一行数据:ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.80.10)(PORT = 1521)

赋值粘贴到 local_listener 中:

local_listener="(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))"

最后在dos窗口中执行命令:

-->sqlplus sys/system as sysdba

-->startup pfile='C:\oracle\product\10.2.0\admin\orcl\pfile\init.ora.816202319487'


注:C:\oracle\product\10.2.0\admin\orcl\pfile\init.ora.816202319487
就是 init.ora.816202319487 文件的全路径

打印出“数据库装载完毕,数据库已经打开”,这个时候再在虚拟机上登录oracle就能成功了,在本机的dbeaver上也能登录成功

问题解决

### Oracle 数据库 ORA-01722: Invalid Number 错误原因及解决方法 #### 错误概述 ORA-01722 是 Oracle 数据库中的常见错误之一,表示尝试将非数值型数据转换为数值时失败。这一问题通常发生在隐式或显式的 `TO_NUMBER` 转换中,当输入值不符合数字格式时触发[^1]。 --- #### 错误发生场景 1. **隐式类型转换** 如果在查询条件中混合了字符串和数字类型的列或参数,Oracle 可能会自动尝试将字符串转换为数字以匹配数据类型。例如: ```sql SELECT * FROM table_name WHERE numeric_column = 'abc'; ``` 上述语句试图将 `'abc'` 转换为数字,但由于其并非合法的数值形式,因此引发 ORA-01722 错误[^1]。 2. **WHERE 子句中的不兼容比较** 当查询涉及跨表连接或其他复杂表达式时,可能出现类似的隐式转换问题。例如: ```sql SELECT * FROM table_a a JOIN table_b b ON TO_NUMBER(a.string_col) = b.number_col; ``` 若 `a.string_col` 中包含任何非数字字符,则会导致错误[^2]。 3. **动态 SQL 或绑定变量** 动态生成的 SQL 语句或者未正确处理的绑定变量也可能引入非法数值。比如传递了一个带有字母的字符串作为预期的整数参数[^3]。 --- #### 解决方案 ##### 方法一:验证并清理数据 确保参与运算的所有字段仅包含有效的数值数据。可以通过以下方式检测潜在问题记录: ```sql SELECT column_name FROM table_name WHERE REGEXP_LIKE(column_name, '[^[:digit:].]'); ``` 这条命令可以帮助识别那些含有除数字以外其他字符(包括但不限于字母、特殊符号)的目标列条目[^1]。 ##### 方法二:强制显式转换 避免依赖数据库自行决定如何实施类型转换,而是明确指出期望的操作模式。对于需要对比字符串与数字的情况,应统一采用同一类别来进行评估。实例演示如下: ```sql -- 将数字转成字符串再做匹配 SELECT * FROM employees e WHERE e.employee_id = TO_CHAR(:input_param); -- 把外部传来的参数视作文字串对待后再变换成相应格式 SELECT * FROM accounts ac WHERE ac.account_no = TO_NUMBER(:param_string); ``` ##### 方法三:应用例外捕获机制 针对某些不可避免会出现杂项内容的情形下,可以考虑运用 PL/SQL 块结合异常处理器来规避风险。样例脚本如下所示: ```plsql BEGIN FOR rec IN ( SELECT some_numeric_field FROM source_table st -- 添加过滤器排除已知干扰因素 WHERE NOT REGEXP_LIKE(st.potential_textual_data, '[^[:digit:]]') ) LOOP DBMS_OUTPUT.PUT_LINE(rec.some_numeric_field); END LOOP; EXCEPTION WHEN OTHERS THEN IF SQLCODE = -1722 THEN NULL; -- 忽略特定种类的差错状况 ELSE RAISE; -- 向上调用链重新抛送其余未知类别的失误事件 END IF; END; ``` ##### 方法四:调整 NLS 参数设置 有时区域环境配置不当也会间接影响到数值解释过程。确认当前会话所使用的本地化选项是否合理至关重要。可通过下面指令查看现有状态以及必要时候加以修正: ```sql ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ',.'; ``` --- ### 总结 综上所述,面对 ORA-01722 错误时需仔细审查相关代码逻辑及其背后的数据质量情况。采取预防措施如提前筛查可疑单元格或是改写易受攻击部位均有助于减少此类麻烦的发生频率。同时保持良好的编程习惯——始终清楚知晓每一步骤里各要素的确切属性亦不失为一种有效策略[^3]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值