-
华为云数据库提供哪些类型的数据库?
-
时序数据库定义时许数据库(Temporal Database)是一种专门用于存储、管理和查询时间序列数据(Temporal Data)的数据库。时间序列数据具有固定的时间间隔,用以表示某个指标在各个时间点的取值。时许数据库为这些数据提供高效的存储、查询和分析功能,以便应用于各种领域,如金融、气象、生物信息学和工业生产等。时序数据库的主要特性高效的数据存储:时许数据库采用特殊的数据结构和方法来存储时间序列数据,以提高数据存储和检索的效率。支持时间索引:时许数据库为时间序列数据建立时间索引,方便基于时间的查询和范围查找。数据压缩和整合:时许数据库通常采用压缩算法和数据整合技术来降低数据存储空间的需求,同时保证数据查询的准确性。实时数据更新:时许数据库支持实时数据更新,以便在新数据到来时进行及时的存储和处理。历史数据查询和分析:时许数据库提供了丰富的查询和分析功能,便于用户回顾历史数据、检测趋势和波动、分析因果关系等。兼容性:许多时许数据库支持与主流关系型数据库(如 MySQL、PostgreSQL 等)的集成,方便用户在不同系统之间进行数据迁移和交换。常见的时序数据库InfluxDB:InfluxDB 是一款开源的分布式时间序列数据库,采用 Go 语言编写,专为处理高并发、高吞吐量的数据采集和查询任务而设计。TimescaleDB:TimescaleDB 是一款基于 PostgreSQL 的时间序列数据库,将 SQL 查询与时间序列数据相结合,适用于低延迟、高可扩展性的应用场景。OpenTSDB:OpenTSDB 是一款分布式、可扩展的时间序列数据库,采用 HBase 作为后端存储,适用于大规模数据存储和查询。Prometheus:Prometheus 是一款开源的监控和报警系统,内置了一个时许数据库,可用于存储和查询各种时间序列数据。 这些时许数据库在各个领域具有广泛的应用,为用户提供了便捷的时间序列数据存储、查询和分析功能。时序数据库的典型应用场景金融领域:时许数据库可用于存储和分析金融市场数据,如股票价格、交易量、汇率等,帮助投资者和金融机构实时监控市场动态、预测趋势、优化投资策略。物联网(IoT):物联网设备产生的时间序列数据(如传感器数据、设备状态等)可以通过时许数据库进行高效存储和分析,从而实现对设备的远程监控、故障预警和性能优化。工业生产:时许数据库可以应用于生产线上的监控和调度,例如生产设备的数据采集、工艺流程的控制和优化、生产进度的跟踪等。气象与环境监测:时许数据库可以存储和分析气象数据、环境监测数据,如气温、湿度、污染物浓度等,用于预测天气变化、空气质量以及环境保护等方面。医疗健康:时许数据库在医疗健康领域的应用包括电子病历管理、医疗设备数据监测、患者数据分析等,有助于提高医疗质量和效率,辅助医生制定个性化治疗方案。智能交通:时许数据库可以用于存储和分析交通数据,如路况监控、交通流量预测、公共交通调度等,提高交通系统的智能化和效率。能源管理:时许数据库可以应用于能源领域的数据存储和分析,如电力、燃气、水资源等,帮助企业实现能源的合理调配、降低成本、提高供应安全性。数据中心运维:时许数据库可以用于监控数据中心各项指标,如服务器性能、网络流量、机房环境等,实现数据中心的智能运维和管理。网络安全:时许数据库可以存储和分析网络安全事件,如攻击日志、异常流量等,实时监控网络安全状况,提高安全防范能力。智能家居:时许数据库可以应用于智能家居设备的数据采集和分析,如传感器数据、家电状态等,实现家庭环境的智能控制和管理。 总之,时许数据库在各个领域具有广泛的应用价值,为实时数据存储、查询和分析提供了强大的支持。
-
服务端通过REST API 接口使用云数据时,如何实现像Android SDK这样的复合查询:两个字段用or连接,只要满足其中一个就可以。
-
鲲鹏云服务有什么优点?
-
1.配置yum源请使用以下命令激活UOSuos-activator-cmd -t如果不激活,配置yum源将失败2.配置openEuler源下载新的openEulerOS.repo到/etc/yum.repos.d/目录下wget -O /etc/yum.repos.d/openEulerOS.repo httpsmirrors.huaweicloud.com/repository/conf/openeuler_aarch64.repo清除原有yum缓存yum clean all生成新的缓存yum makecache3.安装cmake安装依赖yum -y install ncurses ncurses-devel libaio-devel gmp gmp-devel mpfr mpfr-devel libmpcdec zlib-devel net-tools cmake openssl openssl-devel gcc-c++ rpcgen编译安装wget cid:link_1tar zxvf cmake-3.5.2.tar.gzcd cmake-3.5.2/./configure --prefix=/usr/local/cmake-3.5.2make -j96make install修改环境变量export PATH=/usr/local/cmake-3.5.2/bin:$PATH4.安装mysqlFAQ: 使用yum安装的版本为mysql8,当前尝试未能成功启动mysql。所以采用源码编译安装。下载源码并解压wget cid:link_0tar zxvf mysql-boost-5.7.27.tar.gzcd mysql-5.7.27预编译cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql \-DMYSQL_DATADIR=/data \-DSYSCONFDIR=/etc \-DWITH_INNOBASE_STORAGE_ENGINE=1 \-DWITH_PARTITION_STORAGE_ENGINE=1 \-DWITH_FEDERATED_STORAGE_ENGINE=1 \-DWITH_BLACKHOLE_STORAGE_ENGINE=1 \-DWITH_MYISAM_STORAGE_ENGINE=1 \-DENABLED_LOCAL_INFILE=1 \-DENABLE_DTRACE=0 \-DDEFAULT_CHARSET=utf8mb4 \-DDEFAULT_COLLATION=utf8mb4_general_ci \-DWITH_EMBEDDED_SERVER=1 \-DDOWNLOAD_BOOST=1 \-DWITH_BOOST=./boost/boost_1_59_0编译安装make -j96make install#配置环境变量export PATH=/usr/local/mysql/bin:$PATH5.配置MySQL新建配置文件vi /etc/my.cnf#写入以下内容[mysqld]datadir=/datasocket=/var/lib/mysql/mysql.socklog-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid#修改权限chmod 644 /etc/my.cnf创建相关文件及修改权限mkdir /var/lib/mysqlmkdir /var/run/mysqldtouch /var/log/mysqld.logtouch /var/lib/mysql/mysql.socktouch /var/run/mysqld/mysqld.pidchown mysql:mysql /var/log/mysqld.logchown -R mysql:mysql /var/lib/mysqlchown -R mysql:mysql /var/run/mysqld初始化数据库mysqld --initialize --user=mysql生成的文件将在/data下:6.验证加入服务cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqld#启动服务service mysqld start登录初始密码在/var/log/mysqld.log里边可以查找到mysql -uroot -h127.0.0.1 -p
-
学习Mysql数据库需要特殊编译器吗 网上有什么资源去学习?
-
概述 Pod 作为 K8s 中一等公民,其承载了最核心的 Container(s) 的运行。同时,Pod 也是 K8s 中资源调度的最小单位,因此熟悉其初始化过程(包括网络、存储、运行时等)将会使我们更加深入理解 K8s 的容器编排原理,以期更好的服务各类业务。Pod 初始化核心流程如下:kube-apiserver 收到客户端请求(Controller 或 kubectl 客户端)后,创建对应的 Pod; kube-scheduler 按照配置的调度策略进行 Pod 调度,选择最为合适的 Node 作为目标节点; kubelet(运行于每个 Node 上的 K8s agent)Watch 监听到调度到所在节点的 Pod(s),开始真正创建 Pod; 由 CRI 首先创建出 PodSandbox,初始化对应的网络 net namespace,调用 CNI 获取 Pod IP; 接着 CRI 开始创建 Pod 中第一个 pause container,绑定到上一步创建的 net namespace 和 Pod IP; 接着由 CRI 依次创建和启动 Pod 中声明的 initContainers 和 containers 容器; 当所有的 containers 运行起来后,探针探测容器运行符合预期后,Pod 状态最终更新为 Running; 本文将从 K8s 中多种 IP CIDR、Pod 生命周期、kubelet 核心逻辑、CNI IPAM 分配 Pod IP、双协议栈(IPv4/IPv6)、IP 固定与回收等流程,说明 Pod IP 的分配机制。本文基于 K8s v1.27,CRI 已移除 Dockershim。K8s 中多种 IP Pod IP CIDR 在 K8s 中最常见的 IP 类型就是 Pod IP,在初始化 K8s 集群的时候,通过 --cluster-cidr 参数控制 Pod IP CIDR 网段,所有 Pod 动态分配的 IP 都会落在此 CIDR 网段内。具体参数控制如下:通过 kube-controller-manager 组件的 --cluster-cidr 参数进行配置,根据集群规模一般会选择 16 位的网段来配置集群支持的 Pod IP CIDR 网段,如 10.0.0.0/16,理论上最大支持 2 ^ (32 – 16) = 65536 个 Pod IP 的分配。【集群规模】可按需配置 Pod IP CIDR,K8s 官方支持的一个大集群(large cluster),最大支持约 5k Nodes、15w Pods。Node CIDR 在通过 kube-controller-manager 组件的 --cluster-cidr 控制了 Pod IP 的 CIDR 网段后,首先会在集群中每个 Node 分配一个 subnet CIDR,他们都属于 --cluster-cidr 网段。具体参数控制如下:通过 kube-controller-manager 组件的 --allocate-node-cidrs=true、--node-cidr-mask-size=24 参数控制每个 Node 节点的 subnet CIDR 子网段,这样落在每个 Node 上的 Pod 最大的可分配 IP 数量为 2 ^ (32 – 24) = 256 个,各云厂商会根据自己的网络策略,一般会预留一部分,最终可分配的 IP 一般为最大个数的一半 (128 个)。【双协议栈】若开启了 dual-stack IP,则可通过 --node-cidr-mask-size-ipv4=24、--node-cidr-mask-size-ipv6=64 分别控制 IPv4 和 IPv6 的 Node CIDR 子网大小。在 K8s 标准集群中,通过 kubelet 组件的 --max-pods=110 控制了默认一个 Node 最大的 Pod 数量为 110 个。Service IP CIDR 除了上面提到的 Pod IP CIDR 和 Node CIDR 外,K8s 中还有一类 Service IP CIDR,控制 Service 资源的 ClusterIP 网段范围。具体参数控制如下:通过 kube-apiserver 和 kube-controller-manager 组件的 --service-cluster-ip-range=10.96.0.0/12 控制 Service ClusterIP 的网段范围。根据 Service Type 不同,除了 Headless Service 显式将 .spec.clusterIP=None 设置后,生成的 Service 将不会分配 ClusterIP,其他类型的 Service 则都会动态分配 ClusterIP。示例如下:kubectl get svc -n demoNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE demo-clusterip ClusterIP 10.96.0.46 80/TCP 6d11h demo-nodeport NodePort 10.96.0.25 80:31666/TCP 6d11h demo-loadbalancer ClusterIP 10.96.0.250 11.234.50.12 80/TCP 153d demo-headless ClusterIP None 8080/TCP,8081/TCP 20d 需要注意的是,Service 动态分配的 ClusterIP 仅在 K8s 集群内部可访问,通过 K8s 内置的 DNS 进行 Service 域名解析到此 ClusterIP,转发到后端真正的 Pod(s) 时进行流量的负载均衡。【外部访问】若需要从集群外部访问集群内服务,可通过NodePort 或 EXTERNAL-IP 进行访问,还可通过 Ingress 进行更灵活的 L7 (http/https) 流量访问控制。Pod 生命周期 Pod 创建方式 从 kubelet 源码可看到,K8s 支持三种来源方式创建 Pod,分别是 kube-apiserver、staticPodPath、staticPodURL,源码如下:// kubernetes/pkg/kubelet/kubelet.go // 三种创建 Pod 的方式:file, http, apiserver func makePodSourceConfig(kubeCfg *kubeletconfiginternal.KubeletConfiguration, kubeDeps *Dependencies, nodeName types.NodeName, nodeHasSynced func() bool) (*config.PodConfig, error) { ...// define file config source if kubeCfg.StaticPodPath != "" { klog.InfoS("Adding static pod path", "path", kubeCfg.StaticPodPath) config.NewSourceFile(kubeCfg.StaticPodPath, nodeName, kubeCfg.FileCheckFrequency.Duration, cfg.Channel(ctx, kubetypes.FileSource)) }// define url config source if kubeCfg.StaticPodURL != "" { klog.InfoS("Adding pod URL with HTTP header", "URL", kubeCfg.StaticPodURL, "header", manifestURLHeader) config.NewSourceURL(kubeCfg.StaticPodURL, manifestURLHeader, nodeName, kubeCfg.HTTPCheckFrequency.Duration, cfg.Channel(ctx, kubetypes.HTTPSource)) }if kubeDeps.KubeClient != nil { klog.InfoS("Adding apiserver pod source") config.NewSourceApiserver(kubeDeps.KubeClient, nodeName, nodeHasSynced, cfg.Channel(ctx, kubetypes.ApiserverSource)) } return cfg, nil } 其中 kube-apiserver 是最常见的方式,包括通过 kubectl apply -f xxx.yaml 和各类 Controller 动态创建的 Pod 都是这种类型。staticPodPath 主要用途是通过 staticPod 方式创建 K8s 管控组件本身,包括 kube-apiserver, kube-controller-manager, kube-scheduler, etcd 等核心组件,默认路径是 /etc/kubernetes/manifests 目录,kubelet 会持续监听此目录,有对应 yaml 变更时,动态变更对应的 staticPod。staticPodURL 是通过 kubelet 参数 –manifest-url 指定的 HTTP 方式,创建对应 URL 指定的一个或多个 Pod,这种方式实际场景较少使用。通过 staticPodPath、staticPodURL 两种方式创建的 staticPod,kubelet 将转化为 mirrorPod 提交到 kube-apiserver,这样 kubectl get pod 就可以看到了。
-
华为数据库分析数据库是计算机行业的基础核心软件,所有应用软件的运行和数据处理都要与其进行数据交互。2008年阿里提出“去IOE”,而10年之后,我们现在来看,发现Oracle的数据库是最难替换的。不仅是因为Oracle的数据库沉淀了大量的企业客户数据,更是因为数据库产品开发难度确实比较大。数据库的开发难度不亚于操作系统,属于整个IT架构的基础软件(数据库软件在操作系统之上,我们可以将其称为类中间层的基础软件)。而且数据库的开发需要与底层计算架构高度相关和耦合,是适配X86架构,还是适配ARM架构等等。当然以上这些都是数据库的与其他基础器件的适配,数据库难度更大的地方在于如何实现对数据高效、稳定、持续的管理。Oracle、微软的数据库之所以能长久不衰,一方面在于其强大的技术开发和产品升级迭代能力,另一方面在于其对数据库的Knowhow理解足够深,这个是其他厂商短期难以超越的。回到这篇文章的主题:华为数据库。华为在IT的底层架构,逐步搭建起自己的基础架构,建立华为生态。我们这次把华为数据库进行讲解,并对目前主流的数据库进行对比。只有对比,才能发现不同一文了解华为Gauss数据库全内容 华为DB开发历程华为对数据库的开发经历了长达12年左右的时间。2007年,华为开始着手研发内存数据库,项目代号为GMDB。这个项目的背景是,当时电信实施实时计费,电信行业对数据库有特殊的要求,有些需要定制化开发。而当时国外的数据库产品主要是标准化产品。为了满足客户需求,华为当时开始研发内存数据库。2010年,华为开始从内存数据库向通用关系型数据库进行拓展,逐步将非内存数据库的功能融入到数据库产品中。2012年,华为数据库性能得到显著提升,GMDB开始逐步商用化,主要应用于电信计费。同时,该产品也在华为内部的部分部门开始使用。2013年,华为OLTP数据库开始上线(后面我们会详细介绍OLTP和OLAP)。2014年,华为开发出第一个OLAP数据库版本(OLAP我们可以简单理解为:是针对大量数据的分析型数据库)。2015年,华为与工商银行一起联合研发。GaussOLAP数据库在工商银行上线,逐步替代海外的数据仓库。2017年,华为与招商银行一起联合开发GaussDB。同时,华为启动面向事务和分析混合处理的数据库开发,即HTAP。2018年,华为GaussOLTP数据库(事务型数据库)开始在招商银行综合支付交易系统成功上线。承接招商银行“手机银行”和“掌上生活”两大App交易流水流量。2018年,GaussHTAP数据库推出,并在民生银行得到应用。从华为Gauss数据库产品演化至今来看:1)华为数据库产品的研发是从内存数据库开始,逐步向通用关系型数据库延伸,这与Oracle、AWS数据库开发的起点并不完全一样。2)华为数据库产品类型,包括了OLTP、OLAP,同时还研发出HTAP产品。我们认为,从产品应用角度来看,华为OLAP(分析型数据库)大规模应用的时点更早一些。Oracle的OLTP(事务型数据库)在全球领域的竞争优势非常明显,这一领域的数据库产品比较难替代。3)华为的OLTP数据库是通过与大客户合作,特别是银行大客户合作(工商银行、招商银行),来不断进行产品迭代和完善的。我们认为,这也是华为数据库能够快速成长的主要原因。一文了解华为Gauss数据库全内容 初识华为GaussDB华为在数据库领域已经有12年的开发经验,从早期的摸索到现在的产品逐步成熟,中间也是经历了很多历程。目前,华为数据库逐步建立起三大产品系列。华为的数据库产品系列命名为:GaussDB,高斯数据库。高斯,是德国伟大的数学家,近代数学的奠基者之一,高斯、阿基米德、欧拉、牛顿被世人称为世界上最伟大的四位数学家。华为将自己的数据库命名为Gauss系列,也有向数学致敬的意味。GaussDB:开源数据库。华为的Gauss数据库是一个开源数据库,基于PostgreSQL9.2开发。我们知道PostgreSQL本身就是一个开源数据库品牌。现在除了OracleDB、微软的SQLServer等传统老牌数据产品之外,目前新开发的数据库产品,开源数据库占比较大的部分。包括我们看到的AWS的Aurora数据库、阿里的飞天数据库、华为的Gauss数据库,以及数据库新进入者MongoDB等。GaussDB:分布式&AI原生。华为GaussDB是一个企业级AI-Native分布式数据库。GaussDB采用MPP(Massive Parallel Processing)架构,支持行存储与列存储,提供PB(Petabyte,2的50次方字节)级别数据量的处理能力。可以为超大规模数据管理提供高性价比的通用计算平台,也可用于支撑各类数据仓库系统、BI(Business Intelligence)系统和决策支持系统,为上层应用的决策分析提供服务。华为GaussDB将AI能力植入到数据库内核的架构和算法中,为用户提供更高性能、更高可用、更多算力支持的分布式数据库。
-
鲲鹏主机是为高性能计算和大规模数据处理而设计的强大平台。优化鲲鹏主机性能的关键方面之一是数据库调优。调整各种数据库参数和配置以提高其效率和性能。在本教程中,我们将探索鲲鹏主机数据库调优的一些最佳实践。第1步:了解您的工作量在开始任何数据库调优过程之前,了解您的工作负载至关重要。分析您的工作负载可以帮助您识别资源最密集的查询和流程并优化它们以获得更好的性能。第2步:优化内存使用鲲鹏主机提供大量内存,优化内存使用对数据库性能有很大影响。要优化内存使用,请考虑以下事项:为数据库分配足够的内存以避免磁盘I/O操作。为共享缓冲区大小设置适当的值。增加数据库主机可用的最大内存。第3步:调整磁盘I/O性能磁盘I/O是数据库性能的重要组成部分。调整磁盘I/O有助于缩短查询响应时间并减少整体数据库延迟。调整磁盘I/O时请考虑以下事项:使用高速磁盘存储来提高I/O性能。启用预写日志记录以减少所需的磁盘I/O操作数。为数据库块大小设置适当的值。第4步:优化查询执行查询执行是数据库性能的一个重要方面,优化查询执行可以显着提高数据库性能。优化查询执行时请考虑以下事项:创建适当的索引以加速查询执行。调整查询优化器以确保它选择最有效的查询执行计划。避免可能影响数据库性能的复杂查询。第5步:监控数据库性能定期监控数据库性能对于确保最佳数据库性能至关重要。考虑使用性能监控和日志记录工具等工具来识别性能瓶颈并及时解决。鲲鹏主机数据库调优是实现数据库性能最优的关键。了解您的工作负载、优化内存使用、调整磁盘I/O性能、优化查询执行和监控数据库性能是调整过程中的基本步骤。通过遵循这些最佳实践,您可以获得更好的数据库性能并提高鲲鹏主机的效率。
-
mongoDB数据库入门简介及配置MongoDB 是由C++语言编写的,是一个基于分布式文件存储的开源数据库系统。在高负载的情况下,添加更多的节点,可以保证服务器性能。MongoDB 旨在为WEB应用提供可扩展的高性能数据存储解决方案。MongoDB 将数据存储为一个文档,数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档,数组及文档数组1 2 3 4 5 6 { name:"sue", age:23, status:"A", groups:["news","sports"] } mongo功能每个数据库都包含集合,而集合又包含文档。每个文档可以具有不同数量的字段。每个文档的大小和内容可以互不相同。文档结构更符合开发人员如何使用各自的编程语言构造其类和对象。开发人员经常会说他们的类不是行和列,而是具有键值对的清晰结构。从NoSQL数据库的简介中可以看出,行(或在MongoDB中调用的文档)不需要预先定义架构。相反,可以动态创建字段。MongoDB中可用的数据模型使我们可以更轻松地表示层次结构关系,存储数组和其他更复杂的结构。可伸缩性– MongoDB环境具有很高的可伸缩性。全球各地的公司已经定义了自己的集群,其中一些集群运行着100多个节点,数据库中包含大约数百万个文档mongodb使用场景MongoDB (名称来自"humongous") 是一个可扩展的高性能,。MongoDB的主要目标是在键/值存储方式(提供了高性能和高度伸缩性)以及传统的RDBMS系统(丰富的功能)架起一座桥梁,集两者的优势于一身。适用场景网站数据:适合实时的插入,更新与查询,并具备网站实时数据存储所需的复制及高度伸缩性。 缓存:由于性能很高,也适合作为信息基础设施的缓存层。在系统重启之后,搭建的持久化缓存可以避免下层的数据源过载。 大尺寸、低价值的数据:使用传统的关系数据库存储一些数据时可能会比较贵,在此之前,很多程序员往往会选择传统的文件进行存储。 高伸缩性的场景:非常适合由数十或者数百台服务器组成的数据库。 用于对象及JSON数据的存储:MongoDB的BSON数据格式非常适合文档格式化的存储及查询。应用案例纽约时报,领先的在线新闻门户网站之一,使用MongoDBsourceforge.net,资源网站查找,创建和发布开源软件免费,使用MongoDB的后端存储不适合的场景高度事物性的系统:例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。 传统的商业智能应用:针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用,数据仓库可能是更合适的选择。 需要SQL的问题mongodb架构MongoDB 的美妙之处在于为你提供了这些能力:一个简单的单机实例就可以满足大多数小型应用程序的需求。一个多机实例可以为大多数商业应用程序提供持久性 / 高可用性。一个具有水平伸缩能力的大型集群 (分片集群) 可以处理非常大的数据集和大量的查询。MongoDB 提供了自动化基础设施,用于实现分布式的数据分布和处理单服务器/容错设置对于小型应用程序,单台服务器就足以满足频繁的数据备份需求了。如果需要容错,可以使用副本集。在容错配置中,通常有 3 个或更多的 MongoDB 实例。这些实例当中只有一个作为主实例,如果它发生故障,其他两个辅助实例中的一个将成为主实例。这些实例中的数据都是一样的。mongodb管理账户角色管理系统默认角色数据库访问角色1 2 Read:允许用户读取指定数据库 readWrite:允许用户读写指定数据库 数据库管理角色1 2 3 dbAdmin:允许用户在指定数据库中执行管理函数,如索引创建、删除,查看统计或访问system.profile userAdmin:允许用户向system.users集合写入,可以找指定数据库里创建、删除和管理用户 dbOwner: 数据库拥有者(最高), 集合了dbAdmin/userAdmin/readWrite角色的权限 集群管理角色1 2 3 4 clusterAdmin:只在admin数据库中可用,赋予用户所有分片和复制集相关函数的管理权限。 clusterManager: 集群管理角色,允许对分片和副本集集群执行管理操作,如addShard,resync等 clusterMonitor:集群监控角色,允许度分片和副本集集群监控,如查看serverStatus hostManager:节点管理角色,允许监控和管理节点,比如killOp,shutdown等 备份恢复1 2 backup: 备份权限,允许执行mongodump操作 restore:恢复权限,允许执行mongorestore操作 通用角色1 2 3 4 readAnyDatabase:只在admin数据库中可用,赋予用户所有数据库的读权限 readWriteAnyDatabase:只在admin数据库中可用,赋予用户所有数据库的读写权限 userAdminAnyDatabase:只在admin数据库中可用,赋予用户所有数据库的userAdmin权限 dbAdminAnyDatabase:只在admin数据库中可用,赋予用户所有数据库的dbAdmin权限。 特殊角色1 2 root:只在admin数据库中可用。超级账号,超级权限 ——system:内部角色,用于集群节点通讯 创建自定义角色使用createRole命令可以创建自定义角色,每一个角色都需要被绑定到指定的库中。普通的业务库中的角色对象只允许访问当前库的资源对象,而位于admin库的角色则没有此限制。我们定义了一个特殊的角色,用来对分散在多个业务库中的数据进行ETL处理,代码如下常见权限添加mongo 数据管理数据新增数据更新数据删除1 2 3 4 # 删除数据 db.mycol.delete() # 批量删除 db.mycol.deleteMany({}) mongodb安装及使用安装使用1 2 3 4 5 6 7 8 9 # 下载 ## mac版 wget https://downloads.mongodb.com/compass/mongosh-1.0.5-darwin-x64.zip ## linux wget https://downloads.mongodb.com/compass/mongosh-0.1.0-linux.tgz # 连接 主节点: mongo mongodb://mongodb0.example.com.local:27017 从节点: mongo mongodb://mongodb1.example.com.local:27017 副本集: mongo "mongodb://mongodb0.example.com.local:27017,mongodb1.example.com.local:27017,mongodb2.xample.com.local:27017/?replicaSet=replA" mongo数据导入导出下载mongo-tools工具1 2 3 4 wget https://repo.mongodb.org/yum/redhat/7Server/mongodb-org/4.4/x86_64/RPMS/mongodb-database-tools-100.3.1.x86_64.rpm -P /usr/local/src wget https://repo.mongodb.org/yum/redhat/7Server/mongodb-org/4.4/x86_64/RPMS/mongodb-org-tools-4.4.6-1.el7.x86_64.rpm -P /usr/local/src yum localinstall -y mongodb-database-tools-100.3.1.x86_64.rpm yum localinstall -y mongodb-org-tools-4.4.6-1.el7.x86_64.rpm 导出集合数据1 mongoexport --host xxx --port 3717 --authenticationDatabase admin -u admin -p xxxx --db scrm_dimension --collection xxx --type=json --out scrm_dimension.json 导入集合数据1 mongoimport --host xxxx --port 3717 --authenticationDatabase admin -u admin -p xxxx --db scrm_dimension --collection xxxx --type=json --out scrm_dimension.json mongo故障恢复mongo分布式集群MongoDB 有三种集群部署模式,分别为主从复制(Master-Slaver)、副本集(Replica Set)和分片(Sharding)模式。Master-Slaver 是一种主从副本的模式,目前已经不推荐使用。Replica Set 模式取代了 Master-Slaver 模式,是一种互为主从的关系。Replica Set 将数据复制多份保存,不同服务器保存同一份数据,在出现故障时自动切换,实现故障转移,在实际生产中非常实用。Sharding 模式适合处理大量数据,它将数据分开存储,不同服务器保存不同的数据,所有服务器数据的总和即为整个数据集Sharding 模式追求的是高性能,而且是三种集群中最复杂的。在实际生产环境中,通常将 Replica Set 和 Sharding 两种技术结合使用。主从复制主从复制是 MongoDB 中最简单的数据库同步备份的集群技术,其基本的设置方式是建立一个主节点(Primary)和一个或多个从节点(Secondary)。这种方式比单节点的可用性好很多,可用于备份、故障恢复、读扩展等。集群中的主从节点均运行 MongoDB 实例,完成数据的存储、查询与修改操作。主从复制模式的集群中只能有一个主节点,主节点提供所有的增、删、查、改服务,从节点不提供任何服务,但是可以通过设置使从节点提供查询服务,这样可以减少主节点的压力。另外,每个从节点要知道主节点的地址,主节点记录在其上的所有操作,从节点定另外,从节点会定时轮询读取 oplog 日志,根据日志内容同步更新自身的数据,保持与主节点一致。在一些场景中,用户还可以使用副本集来扩展读性能,客户端有能力发送读写操作给不同的服务器,也可以在不同的数据中心获取不同的副本来扩展分布式应用的能力。在副本集中还有一个额外的仲裁节点(不需要使用专用的硬件设备),负责在主节点发生故障时,参与选举新节点作为主节点。副本集中的各节点会通过心跳信息来检测各自的健康状况,当主节点出现故障时,多个从节点会触发一次新的选举操作,并选举其中一个作为新的主节点。为了保证选举票数不同,副本集的节点数保持为奇数。分片副本集可以解决主节点发生故障导致数据丢失或不可用的问题,但遇到需要存储海量数据的情况时,副本集机制就束手无策了。副本集中的一台机器可能不足以存储数据,或者说集群不足以提供可接受的读写吞吐量。这就需要用到 MongoDB 的分片(Sharding)技术,这也是 MongoDB 的另外一种集群部署模式。分片是指将数据拆分并分散存放在不同机器上的过程。有时也用分区来表示这个概念。将数据分散到不同的机器上,不需要功能强大的大型计算机就可以存储更多的数据,处理更大的负载。MongoDB 支持自动分片,可以使数据库架构对应用程序不可见,简化系统管理。对应用程序而言,就如同始终在使用一个单机的 MongoDB 服务器一样。MongoDB 的分片机制允许创建一个包含许多台机器的集群,将数据子集分散在集群中,每个分片维护着一个数据集合的子集。与副本集相比,使用集群架构可以使应用程序具有更强大的数据处理能力。构建一个 MongoDB 的分片集群,需要三个重要的组件,分别是分片服务器(Shard Server)、配置服务器(Config Server)和路由服务器(Route Server)。Shard Server每个 Shard Server 都是一个 mongod 数据库实例,用于存储实际的数据块。整个数据库集合分成多个块存储在不同的 Shard Server 中。 在实际生产中,一个 Shard Server 可由几台机器组成一个副本集来承担,防止因主节点单点故障导致整个系统崩溃。Config Server这是独立的一个 mongod 进程,保存集群和分片的元数据,在集群启动最开始时建立,保存各个分片包含数据的信息。Route Server这是独立的一个 mongos 进程,Route Server 在集群中可作为路由使用,客户端由此接入,让整个集群看起来像是一个单一的数据库,提供客户端应用程序和分片集群之间的接口。Route Server 本身不保存数据,启动时从 Config Server 加载集群信息到缓存中,并将客户端的请求路由给每个 Shard Server,在各 Shard Server 返回结果后进行聚合并返回客户端。
-
OSI参考模型的简介1、为了更好地促进互联网络的研究和发展,国际标准化组织ISO制定了网络互连的七层框架的一个参考模型,称为开放系统互连参考模型,简称OSI/RM(Open System Internetwork Reference Model)。 OSI参考模型是一个具有7层协议结构的开放系统互连模型,是由国际标准化组织在20世纪80年代早期制定的一套普遍适用的规范集合,使全球范围的计算机可进行开放式通信。2、OSI参考模型是一个具有七层结构的体系模型。发送和接收信息所涉及的内容和相应的设备称为实体。OSI的每一层都包含多个实体,处于同一层的实体称为对等实体。3、OSI参考模型也采用了分层结构技术,把一个网络系统分成若干层,每一层都去实现不同的功能,每一层的功能都以协议形式正规描述,协议定义了某层同远方一个对等层通信所使用的一套规则和约定。每一层向相邻上层提供一套确定的服务,并且使用与之相邻的下层所提供的服务。从概念上来讲,每一层都与一个远方对等层通信,但实际上该层所产生的协议信息单元是借助于相邻下层所提供的服务传送的。因此,对等层之间的通信称为虚拟通信。4、OSI参考模型是一个具有七层次的框架,自底向上的七个层次分别为:物理层(物理介质,比特流)、数据链路层(网卡、交换机)、网络层(IP协议)、传输层(TCP/UDP协议)、会话层(创建/建立/断开连接)、表示层(翻译,编码,压缩,加密)、应用层(HTTP协议)。★国家标准化组织(ISO)于1979年建立了OSI参考模型。OSI层次划分原则(1)网络中各结点都具有相同的层次。(2)不同结点的同等层具有相同的功能。(3)同一结点内相邻层之间通过接C ]通信。(4)每个层可以使用下层提供的服务,并向其上层提供服务。(5)不同结,点的同等层通过协议来实现对等层之间的通信。OSI划分层次结构的优越性(1)各层之间相互独立,即不需要知道低层的结构,只要知道是通过层间接口所提供的服务。(2)灵活性好,即只要服务和接C ]不变,层内实现方法可任意改变。(3)各层都可以采用:最合适的技术实现而不影响其他层。(4)易于实现和维护。有利于促进标准化,是因为每层的功能和提供的服务都已经有了精确的说明。OSI层次结构模型OSI参考模型的特点(1)每个层次的对应实体之间都通过各自的协议通信。(2)各个计算机系统都有相同的层次结构。(3)不同系统的相应层次有相同的功能。(4)同一系统的各层次之间通过接口联系。(5)相邻的两层之间,下层为上层提供服务,同时上层使用下层提供的服务。OSI参考模型的各层功能(1)物理层OSI参考模型的最低层,建立在通信介质基础上,实现设备之间的物理接口,以便透明地传送“比特”流。物理层传输的单位是比特(Bit) ,即0和1,也就是最基本的电信号或光信号,是最基本的物理传输特征。物理层标准要给出关于物理接口的机械、电气、功能和规程特性,以便于不同的制造厂家既能够根据公认的标准各自独立地制造设备,又能使各个厂家的产品能够相互兼容。(2)数据链路层提供数据的流量控制检测和纠正物理链路产生的差错。在物理层提供比特流传输服务的基础上,数据链路层(Data Link Layer )通过在通信的实体之间建立数据链路连接,传送以“帧”为单位的数据,使有差错的物理线路变成无差错的数据链路,保证点到点可靠的数据传输。(3)网络层负责信息寻址,将逻辑地址和名字转换为物理地址。是OSI参考模型中的第三层,它建立在数据链路层所提供的两个相邻节点间数据帧的传送功能之上,将数据从源端经过若干中间节点传送到目的端。(4)传输层传输层关心的主要问题是建立、维护和拆除传输连接。主要目的是向用户提供无差错可靠的端到端(end-to-end )服务,透明地传送报文,提供端到端的差错恢复和流量控制。由于它向高层屏蔽了下层数据通信的细节,因而是计算机通信体系结构中最关键的一层。(5)会话层就像它的名字一样,会话谣(Session Layer )实现建立管理和终止应用程序进程之间的会话和数据交换,即指通信双方一次完整的信息交互,负责发起、维护、终止应用程序之间的通信(会话)。会话层协议涉及传输方式(半双工、全双工)、会话质量(传输延迟、吞吐量等)等方面的标准。(6)表示层表示层(Presentation Layer )保证一个系统应用层发出的信息能被另一个系统的应用层读出,即规定了计算机之间交换数据的格式。负责数据格式的转换、压缩与解压缩、加密与解密。(7) 应用层应用层(Application Layer )是OSI参考模型中最靠近用户的一层,是应用程序访问网络服务的接C ],它为用户的应用程序提供网络服务,这些应用程序包括电子数据表格程序、字处理程序和银行终端程序等。应用层的协议很多,如支持万维网的HTTP协议,支持电子邮件的SMTP协议,支持文件传输的FTP协议等等。OSI参考模型的优点(1)、分工合作,责任明确。性质相似的工作划分在同一层,性质相异的工作则划分到不同层。如此一来,每一层所负责的工作范围,都区分得很清楚,彼此不会重叠。万一出了问题,很容易判断是哪一层没做好,就应该先改善该层的工作,不至于无从着手。  (2)、对等交谈对等是指所处的层级相同,对等交谈意指同一层找同一层谈,例如:第3层找第3层谈、第4层找第4层谈…依此类推。所以某一方的第N层只与对方的第N层交谈,是否收到、解读自己所送出的信息即可,完全不必关心对方的第N-1层或第N+1层会如何做,因为那是由一方的第N-1层与第N+1层来处理。双方以对等身份交谈是常用的规则,这样的最大好处是简化了各层所负责的事情。因此,通信协议是对等个体通信时的一切约定。(3)、逐层处理,层层负责既然层次分得很清楚,处理事情时当然应该按部就班,逐层处理,决不允许越过上一层,或是越过下一层。因此,第N层收到数据后,一定先把数据进行处理,才会将数据向上传送给第N+1层,如果收到第N+1层传下来的数据,也是处理无误后才向下传给第N-1层。任何一层收到数据时,都可以相信上一层或下一层已经做完它们该做的事,层级的多少还要考虑效率与实际操作的难易,并非层数越多越好。
-
##[TCP/IP协议简介TCP/IP传输协议,即传输控制/网络协议,也叫作网络通讯协议。它是在网络的使用中的最基本的通信协议。TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定。并且,TCP/IP传输协议是保证网络数据信息及时、完整传输的两个重要的协议。TCP/IP传输协议是严格来说是一个四层的体系结构,应用层、传输层、网络层和数据链路层都包含其中。TCP/IP协议是Internet最基本的协议,其中应用层的主要协议有Telnet、FTP、SMTP等,是用来接收来自传输层的数据或者按不同应用要求与方式将数据传输至传输层;传输层的主要协议有UDP、TCP,是使用者使用平台和计算机信息网内部数据结合的通道,可以实现数据传输与数据共享;网络层的主要协议有ICMP、IP、IGMP,主要负责网络中数据包的传送等;而网络访问层,也叫网路接口层或数据链路层,主要协议有ARP、RARP,主要功能是提供链路管理错误检测、对不同通信媒介有关信息细节问题进行有效处理等。TCP/IP协议四个层次1.应用层(Application layer):是TCP/IP体系结构中的最高层,应用层包括了所有高层协议,并且总是不断有新的协议加2.运输层(Transport layer):也称为应用程序到应用程序层。与OSI的传输层类似主要负责应用程序到应用程序之间的端对端通信。◆传输层的主要功能:在互联网中源机与目的主机的对等实体间建立用于会话的端对端连接。◆传输层主要有两个协议:即传输控制协议(TCP)和用户数据报协议(UDP)。3.网络层(Internet layer):与OSI参考模型的网络层相当,是整个TCP/IP体系结构的关键部分。◆网络层的主要功能:(1)处理来自传输层的分组发送请求,在收到分组发送请求之后,将分组装入IP数据报,填充报头,选择好发送路径,然后将数据报发送到相应的网络输出端;(2)处理接收的数据报,在接收到其他主机发送的数据报之后,检查目的地址,如需要转发,则选择发送路径,转发出去,如目的地址为本结点IP地址,则除去报头,将分组交送传输层处理;(3)处理互联的路径选择、流量控制与拥塞问题;4.网络接口层(Internet interface layer):最底层,负责将数据包送到电缆上是实际的网络硬件接口,对应于OSI参考模型的物理层和数据链路层。实际上,TCP/ IP并没有定义具体的网络接口协议,而是旨在提供灵活性,以适应各种网络类型。如LAN MAN和WAN,这也说明了TCP/ IP可以运行在任何网络之上,这也为TCP/ IP的成功打下了基础。OSI模型与TCP/IP协议的对应TCP/IP 具有的特点①开放的协议标准,可以免费使用并且独立于特定的计算机硬件与操作系统;②独立于特定的网络硬件,可以运行在局域网、广域网中更适用于互联网;③统一的网络地址分配方案,使得整个TCP/ IP设备在网络中都具有唯一的地址;④标准化的高层协议,可以提供多种可靠的用户服务。TCP/IP协议三次握手●TCP握手协议,在TCP/IP协议中TCP协议提供可靠的连接服务,采用三次握手建立一个连接。●第一次握手:▷建立连接时客户端发送 syn包(syn=j)到服务器.并进入SYN_SEND状态等待服务器确认。●第二次握手:▷服务器收到syn包必须确认客户的SYN (ack = j + 1)。同时自己也发送一-个 SYN包(syn = k)。即SYN+ ACK包此时服务器进入SYN_RECV 状态。●第三次握手:▷客户端收到服务器的SYN+ ACK包向服务器发送确认包ACK(ack = k + 1)此包发送完毕客户端和服务器进入ESTABLISHED状态,完成三次握手。●完成三次握手,客户端与服务器开始传送数据。TCP/IP协议簇TCP/IP协议簇是Internet的基础,也是当今最流行的组网形式。TCP/IP是一组协议的代名词,包括许多别的协议,组成了TCP/IP协议簇。其中比较重要的有SLIP协议、PPP协议、IP协议、ICMP协议、ARP协议、TCP协议、UDP协议、FTP协议、DNS协议、SMTP协议等。TCP/IP协议并不完全符合OSI的七层参考模型。传统的开放式系统互连参考模型,是一种通信协议的7层抽象的参考模型,其中每一层执行某一特定任务。该模型的目的是使各种硬件在相同的层次上相互通信。而TCP/IP通讯协议采用了4层的层级结构,每一层都呼叫它的下一层所提供的网络来完成自己的需求。注:关于个各层协议的简介以及特点不在一一细说!
-
一、变更规范 范围 ● 上线变更:代码上线、回滚、扩缩容; ● 配置变更:系统配置、应用配置; ● 网络变更:网络割接、设备更换; ● 其它变更:流量调度、服务切换、服务下线...原则 a、制定变更审核流程; b、制定变更相关方通知(群、邮件); c、制定变更回滚策略; d、遵循测试、灰度、全量上线的规则; e、下线变更要将服务器依赖处理干净,比如说挂着vip、有域名解析。二、容灾规范 范围 ● 服务灾备:多机器、多机房; ● 数据灾备:多备份、异地备份; ● 网络灾备:多线路、多设备;原则 a、自动切换 好于 手动切换; b、无状态 好于 有状态; c、热备 好于 冷备; d、多机房 好于 单机房。三、容量规范 范围 ● 系统容量:木桶原理计算系统的全链路容量、用量、余量; ● 模块容量:模块的容量、用量、余量; ● 机房容量:分机房的容量、用量、余量; ● 单机容量:用于反向计算机房、模块容量;原则 a、制定模块单机容量指标(比如QPS、连接数、在线用户数等); b、容量要考虑下行(读)、上行(写),考虑存储增量; c、计算当前模块总容量,收集当前的用量,并对比容量计算余量; d、系统总容量可以根据木桶原理,找到短板模块后,反向计算出来四、巡检规范 范围 ● 用户核心指标; ● 服务核心指标; ● 基础资源指标:服务器; ● 依赖资源指标:依赖db、依赖接口; ● 自动化巡检报告; ● 值班oncall安排;原则 a、DashBoard核心在于收敛、舍得; b、自动化巡检的必要性在于异常侦测,预防故障。五、告警规范 范围 ● 基础监控:CPU、内存、网络、IO; ● 应用监控:进程、端口; ● 业务监控:日志、业务埋点; ● 依赖监控:数据库、依赖接口...原则 a、核心监控收敛成告警,并对告警进行分级,备注告警影响; b、核心监控形成可排查问题的DashBoard; c、告警的价值在于实时发现故障。六、预案规范 范围 ● 线路切换:移动、电信、联通线路切换; ● 机房切换:不同机房切换; ● 机器切换:机器故障时进行摘除; ● 服务降级:无法切换时,降低标准继续服务; ● 数据库切换:主从切换、读写切换; ● 网络切换:主备线路切换、链路切换;原则 a、域名切换 好于 更换IP; b、自动摘除 好于 手动操作; c、自动切换 好于 手动切换; d、考虑好雪崩事宜。七、故障管理规范 范围 ● 服务分级:确定各服务用户角度的影响; ● 故障定级:制定故障定级标准; ● 制定故障通知、处理规范; ● 制定故障复盘,改进措施按时保量完成的规范;原则 a、拥抱故障,同类故障不能重复发生。八、权限安全规范 范围 ● 开发、运维、临时权限; ● 安全上符合安全审计标准。九、文档、工具规范 范围 ● 统一共享知识文档; ● 统一共享各种脚本工具;原则 a、理想的情况是“一站式运维平台”,一个平台涵盖所有工具操作。十、标准化规范 范围 ● 主机名标准化; ● 日志存储标准化; ● 日志格式标准化; ● 域名使用标准化; ● 软件安装目录结构标准化; ● 服务及相关的组件使用命令标注化;原则 a、主机名尽量能看出更多信息,比如服务、模块、机房等; b、日志是排查问题的重要信息,一定要标准化,方便手工排查,更是为了以后用工具处理打下基础。十一、资源管理规范 范围 ● 服务器 ● vip ● 域名 ● 证书 ● 代码 ● k8s ● 数据库 ● 中间件原则 a、资源之间是有关系的,要建立有关系的资源管理
-
枕边小记忆:MySQL -- 技巧提升篇** 1 、1=1,1=2的使用,在SQL语句组合时用的较多**“where 1= 1”是表示选择全部 “where 1=2”全部不选, 如: if @strWhere !='' begin set @strSQL = 'select count() as Total from [' + @tblName + '] where ' + @strWhere end else begin set @strSQL = 'select count() as Total from [' + @tblName + ']' end我们可以直接写成错误!未找到目录项。 ** set @strSQL = 'select count(*) as Total from [' + @tblName + '] where 1=1 安定 '+ @strWhere 2、收缩数据库 **--重建索引 DBCC REINDEX DBCC INDEXDEFRAG --收缩数据和日志 DBCC SHRINKDB DBCC SHRINKFILE**3 、压缩数据库**dbcc shrinkdatabase(dbname)**4 、转移数据库给新用户以已存在用户权限**exec sp_change_users_login 'update_one','newname','oldname' go**5 、检查备份集**RESTORE VERIFYONLY from disk='E:\dvbbs.bak'**6 、修复数据库**ALTER DATABASE [dvbbs] SET SINGLE_USER GO DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK GO ALTER DATABASE [dvbbs] SET MULTI_USER GO**7 、日志清除**SET NOCOUNT ON DECLARE @LogicalFileName sysname, @MaxMinutes INT, @NewSize INTUSE tablename -- 要操作的数据库名 SELECT @LogicalFileName = 'tablename_log', -- 日志文件名 @MaxMinutes = 10, -- Limit on time allowed to wrap log. @NewSize = 1 -- 你想设定的日志文件的大小(M)Setup / initialize DECLARE @OriginalSize int SELECT @OriginalSize = size FROM sysfiles WHERE name = @LogicalFileName SELECT 'Original Size of ' + db_name() + ' LOG is ' + CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB' FROM sysfiles WHERE name = @LogicalFileName CREATE TABLE DummyTrans (DummyColumn char (8000) not null)DECLARE @Counter INT, @StartTime DATETIME, @TruncLog VARCHAR(255) SELECT @StartTime = GETDATE(), @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'DBCC SHRINKFILE (@LogicalFileName, @NewSize) EXEC (@TruncLog) -- Wrap the log if necessary. WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName) AND (@OriginalSize * 8 /1024) > @NewSize BEGIN -- Outer loop. SELECT @Counter = 0 WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000)) BEGIN -- update INSERT DummyTrans VALUES ('Fill Log') DELETE DummyTrans SELECT @Counter = @Counter + 1 END EXEC (@TruncLog) END SELECT 'Final Size of ' + db_name() + ' LOG is ' + CONVERT(VARCHAR(30),size) + ' 8K pages or ' + CONVERT(VARCHAR(30),(size*8/1024)) + 'MB' FROM sysfiles WHERE name = @LogicalFileName DROP TABLE DummyTrans SET NOCOUNT OFF**8 、说明:更改某个表**exec sp_changeobjectowner 'tablename','dbo'9 、存储更改全部表 ****CREATE PROCEDURE dbo.User_ChangeObjectOwnerBatch @OldOwner as NVARCHAR(128), @NewOwner as NVARCHAR(128) ASDECLARE @Name as NVARCHAR(128) DECLARE @Owner as NVARCHAR(128) DECLARE @OwnerName as NVARCHAR(128)DECLARE curObject CURSOR FOR select 'Name' = name, 'Owner' = user_name(uid) from sysobjects where user_name(uid)=@OldOwner order by nameOPEN curObject FETCH NEXT FROM curObject INTO @Name, @Owner WHILE(@@FETCH_STATUS=0) BEGIN if @Owner=@OldOwner begin set @OwnerName = @OldOwner + '.' + rtrim(@Name) exec sp_changeobjectowner @OwnerName, @NewOwner end -- select @name,@NewOwner,@OldOwnerFETCH NEXT FROM curObject INTO @Name, @Owner ENDclose curObject deallocate curObject GO**10 、SQL SERVER中直接循环写入数据**declare @i int set @i=1 while @i<30 begin insert into test (userid) values(@i) set @i=@i+1 end 案例 **:** 有如下表,要求就裱中所有沒有及格的成績,在每次增長 0.1的基礎上,使他們剛好及格:Name scoreZhangshan 80Lishi 59Wangwu 50Songquan 69while((select min (score) from tb_table) < 60 )beginupdate tb_table set score = score* 1.01 ****where score < 60 ****if (select min (score) from tb_table) > 60 ****breakelsecontinueend
上滑加载中
推荐直播
-
TinyEngine低代码引擎系列.第1讲——低代码浪潮之下,带你走进TinyEngine
2024/11/11 周一 16:00-18:00
李老师 高级前端开发工程师
低代码浪潮之下,带你走进TinyEngine。李旭宏老师将从低代码的发展趋势、TinyEngine的项目介绍,三方物料组件的使用、跨技术栈的使用、源码生成能力的差异性对比等多个方面带大家对TinyEngine低代码引擎有一个更清晰的认知和了解。
即将直播 -
0代码智能构建AI Agent——华为云AI原生应用引擎的架构与实践
2024/11/13 周三 16:30-18:00
苏秦 华为云aPaaS DTSE技术布道师
大模型及生成式AI对应用和软件产业带来了哪些影响?从企业场景及应用开发视角,面向AI原生应用需要什么样的工具及平台能力?企业要如何选好、用好、管好大模型,使能AI原生应用快速创新?本期直播,华为云aPaaS DTSE技术布道师苏秦将基于华为云自身实践出发,深入浅出地介绍华为云AI原生应用引擎,通过分钟级智能生成Agent应用的方式帮助企业完成从传统应用到智能应用的竞争力转型,使能千行万业智能应用创新。
去报名
热门标签