Python程序生产环境离线部署纪要

最近做了一个Python Django应用,到生产环境部署的工作,总结备忘。基本特征: 1. Linux环境的Python一般都还是2.7 2. 开发环境的Python总是越高越好,本例是3.7 3. 生产环境没有外网连接,没有yum源、pypi 安装Python 3.7: 需要libffi-devel 升级的openssl版本需要 编译安装时 ./configure —prefix=/usr/local/python3.7 —with-openssl=/opt/openssl1.0.1/ python 3.7 自带virtualenv(创建自己的venv,不要覆盖Linux的python默认环境) python -m venv <venv_dir> 开发测试环境的准备: pip freeze > requirements.txt 使用pip下载离线wheel pip download -d packages -r requirements.txt or pip wheel —wheel-dir=packages -r requirements.txt 完成这一步后,需要的python wheel就都保存在packages文件夹下了,但是有一个需要注意特别处理的问题,就是开发平台可能和部署平台不一致问题——有些下载的wheel文件是平台相关的,比如我的开发环境是mac,那这个文件名就带macos,这种情况下,需要手工下载生产环境对应平台文件——linux x86_64之类的。 pyzmq、SQLAlchemy都存在这个问题。将相关文件copy到生产环境,在之前准备的venv下: pip3 install —no-index —find-links=packages -r requirements.txt

Oracle 19c CRS重启案例记录

对文件系统进行较大写入操作(30g文件写入),导致RAC一个节点被驱逐重启。 MOS info:Bug 30472602 CRS: oracssdagent is rebooting this node because the file system did not respond This note gives a brief overview of bug 30472602. The content was last updated on: 15-JAN-2020 Click here for details of each of the sections below.Affects: Product (Component) Oracle Server (PCW)Range of versions believed to be affected Versions

Oracle CRS 启动问题诊断

  #工程师培训# #CRS# 从10g开始,Oracle使用自己的CRS管理RAC集群,到了11g、12c,voting disk,ocr,共享存储等等都由Oracle自己的集群软件管理(从11g开始,名称由CRS调整为GI——Grid Infrastructure)。 对外提供服务的数据库集群,依赖于底层GI。而GI要求共享存储、网络通讯、节点间进程通讯都准备就绪,才能正常运行。GI本就是由许多组件构成的集群(复杂)管理系统,雪上加霜的是,由于GI的日志输出中,有过多的Info级别的信息,且各个组件都有自己的日志,这些都造成了如果GI启动不成功,定位故障点比较困难。 本文结合MOS 《Troubleshoot Grid Infrastructure Startup Issues》一文对GI启动问题进行梳理。 首先还是来说日志,先要能确定其存储位置: Oracle 10g, 存储于$GRID HOME/log/name>/… ,当然在10g中其实还没有明确定义GRID HOME。 Oracle 11g, $GRID HOME/log/name>/ , 好像跟10g的没有区别 Oracle 12c,发生了改变,不加注意,容易在出问题时找不到日志 3.1 Standard cluster: $ORACLE_BASE/diag/crs/… 位置发生了改变,并且彻底使用ADR来管理日志。 3.2 Flex cluster: $ORACLE HOME/log/name>  因为Grid Infrastructure组件较多(CRSD,CSSD,EVENTD…),所以日志也就很多,总体来说,应该先查看alert.log ,再查看各组件的日志。 即使你已经对于去哪里能找到Grid Infrastructure的日志很清楚,真正面对目录中那么多日志、trace,以及日志中不知道什么意思的各种输出,很容易迷失。我的经验是,在“陷入”日志之前,先从操作系统角度查找一下,有没有什么明显的问题,导致Grid Infra不能启动。 OS级别的检查: 网络PING,将/etc/hosts中定义的,集群内的各个IP都ping一下 共享存储,以及其权限 文件系统空间使用、inode使用(Grid Infra经常因为产生日志太多,用尽inode,把自己撑死) … 总觉得还有别的,以后想到再补充 GI 启动顺序 操作系统启动ohasd —》

使用SQL*Plus生产CSV格式数据

使用SQL*Plus生产CSV格式数据 #工程师培训 #sqlplus# 因为Excel、很多BI工具、甚至一些数据库,都支持直接导入CSV(comma separated value)格式数据,所以一直以来,我们都有将Oracle数据库中表的数据行导出成为CSV格式的需求。从Oracle 12.2.0.1开始,SQL*Plus支持将查询输出为CSV格式。本文对此新特性进行演示。 演示环境 [SQL*Plus] CREATE TABLE BOOKS (
 BOOK_ID NUMBER GENERATED ALWAYS AS IDENTITY,
 TITLE VARCHAR2(250) NOT NULL,
 PAGES NUMBER NOT NULL,
 AUTHOR VARCHAR2(250) NOT NULL,
 CONDITION VARCHAR2(4000),
 CONSTRAINT BOOKS_PK PRIMARY KEY (BOOK_ID),
 CONSTRAINT BOOKS_UQ UNIQUE (TITLE)
);
 
[SQL*Plus] INSERT INTO BOOKS (TITLE, PAGES, AUTHOR, CONDITION) VALUES ('The Hobbit', 322, 'J.

检查Oracle redo log切换频率的SQL

这个SQL的特点是模拟日历(Calendar)形式,显示每小时产生的redo log数量: SELECT * FROM (SELECT A.* FROM (SELECT * FROM (SELECT TO_DATE(b.date_time, 'DD/MM/YYYY') dt,TO_CHAR(TO_DATE(b.date_time, 'DD/MM/YYYY'), 'DAY') DAY,"00", "01", "02", "03", "04", "05", "06", "07", "08", "09","10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", TOTALFROM (SELECT date_time,SUM(DECODE(HOUR,'00',1,NULL)) "00", SUM(DECODE(HOUR,'01',1,NULL)) "01", SUM(DECODE(HOUR,'02',1,NULL)) "02",SUM(DECODE(HOUR,'03',1,NULL)) "03", SUM(DECODE(HOUR,'04',1,NULL)) "04", SUM(DECODE(HOUR,'05',1,NULL)) "05",SUM(DECODE(HOUR,'06',1,NULL)) "06", SUM(DECODE(HOUR,'07',1,NULL))

获取用户User,对象Object的DDL定义

  获取用户、用户权限的DDL语句 [code language="sql"]set feedback off pages 0 long 90000 serveroutput onaccept USERNAME prompt "Enter username :" [/code] 获取对象、相关对象的DDL 特定表的DDL: [code language="sql"]SET LONG 2000000 SET PAGESIZE 0 SELECT DBMS_METADATA.GET_DDL(TABLE,EMP’,’SCOTT’) FROM DUAL; [/code]   获取表相关的授权: [code language="sql"]SET LONG 2000000 SET PAGESIZE 0 SELECT DBMS_METADATA.GET_DEPENDENT_DDL(‘OBJECT_GRANT’,’EMP’,’SCOTT’) FROM DUAL; [/code]   获取指定schema(这里用scott举例)的所有表DDL: [code language="sql"]-- ### Schema all object DDL

VEGA Transform功能

  Vega 学习 #BI/大数据 Transform aggregate 聚合操作,fields 和 ops 两个数组对应,产生的结果在as 属性中指明: [ {“foo”: 1, "bar": 1}, {“foo”: 1, “bar”: 2}, {“foo”: null, “bar”: 3} ] 执行aggregate 转换 { “type”: "aggregate”, “fields”: [“foo”, “bar”, “bar”], “ops”: [“valid”, “sum”, “median”], "as": ["v", "s", "m"] } 结果 [{“v”: 2, "s": 6, "m”: 2}] 以上是对所有数据集进行聚合操作,结果为1行数据,可使用groupby,产生分组数据: [ {“foo”: "a", "bar”:

打开JDK及其他底层API日志接口,诊断程序问题

#Java/JMX 遇到一个问题,使用JMX 连接Tomcat,连接的IP是10.1.0.?,在创建连接的时候,会抛出网络连接超时的Exception,迷茫的是,Exception中提示是10.0.0.?的网络连接超时。 一时各种怀疑,但是都找不到问题;后在stackoverflow 上找到打开JMX日志的方式,觉得此方法具有解决这一类问题的通适性。 创建属性文件(.properties)```handlers= java.util.logging.ConsoleHandler.level=ALL java.util.logging.FileHandler.pattern = jmx.logjava.util.logging.FileHandler.limit = 50000java.util.logging.FileHandler.count = 1java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter java.util.logging.ConsoleHandler.level = FINESTjava.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter // Use FINER or FINEST for javax.management.remote.level - FINEST is// very verbose...//javax.management.level=FINESTjavax.management.remote.level=FINEST java.security.debug=all``` 在调用测试程序时,配置使用上述属性文件:```java -Djava.util.logging.config.file=./logging.properties JMXDemoClient ``` _假设你的测试程序被编译为 JMXDemoClient.class_ 通过这种方式,在我的案例中,日志清楚的显示,是JMX Server(此处是Tomcat)要客户端去跟10.0.0.? 连接;所以一定是Tomcat端的配置有问题,进行检查后,发现服务器IP地址变更后,`java.rmi.server.hostname` 没有做更新,仍然是原来的IP地址。 总结: 通过调整属性文件,可以输出任意底层API的各种级别日志。

使用Logstash JDBC获取Oracle数据的小问题

需要将Oracle中的数据,通过Logstash JDBC input插件,写入到Elasticsearch中,遇到了一个因为时间类型设置不正确导致的性能问题。为了能够不断的将数据增量写入Elasticsearch,做了如下配置: record_last_run => true        tracking_column => "mark_datetime"       tracking_column_type => "timestamp"        use_column_value => true 这里设置tracking_column_type出现了问题,数据库表中mark_datetime字段是Date类型。虽然整个pipline能够运行无误,但是运行效率发现不够好。到Oracle数据库中检查,发现SQL语句变成了 SYS_EXTRACT_UTC("M"."MARK_DATETIME")>TIMESTAMP' 2015-07-19 11:17:03.000000000’ 这就导致了MARK_DATETIME上现有的索引不能使用。Oracle在Date和Timestamp之间自动做了转换。